Короткий ответ
«Малоценная или маловостребованная страница» — статус исключённых страниц в Яндекс Вебмастере, в выгрузке он обозначается кодом LOW_DEMAND. Робот знает URL, но алгоритм решил не показывать его в поиске: страница дублирует известный документ, не содержит видимого роботу контента либо не отвечает реальным запросам пользователей. Это не санкция. Порядок работы: классифицировать URL (нужен ли он в поиске), найти причину из трёх названных, выбрать одно действие — доработка, объединение, canonical, noindex, 301, 404/410 — и отправить страницу на переобход.
Статус пугает объёмом: в средних интернет-магазинах в «Исключённых страницах» лежат десятки тысяч адресов, и почти все они помечены одинаково. Отсюда две типичные ошибки — либо игнорировать список целиком, либо кинуться дорабатывать тексты на всех URL подряд.
Ни то, ни другое не работает, потому что под одним статусом Яндекс объединяет как минимум три разные причины, и лечатся они разными действиями. Ниже — что именно означает статус по официальной справке, как вытащить из Вебмастера данные для массового разбора, как за полчаса определить причину для конкретного URL и сколько времени занимает каждое из решений.
Что означает статус
Формулировка Яндекса из справки: алгоритм может не включать страницу в поиск, если у неё мало шансов оказаться востребованной пользователями. Дальше названы три примера причин:
- страница дублирует уже известные роботу страницы;
- страница не содержит контента;
- контент не совсем соответствует запросам пользователей.
Ключевая часть определения — «автоматический регулярный процесс, поэтому решение алгоритма о включении в поиск конкретной страницы может измениться». То есть это не пометка «навсегда», а текущая оценка, которая пересчитывается почти каждый день.
Из этого следует практический вывод, который экономит много времени: сам факт наличия статуса — не проблема. Проблема — состав списка. Сотни выпавших сортировок и UTM-меток нормальны, а вот категория с продажами или страница услуги в этом списке означает потерянный трафик и заявки прямо сейчас.
Где смотреть и как выгрузить
Путь в интерфейсе: Индексирование → Страницы в поиске → Исключённые страницы, фильтр «Малоценная или маловостребованная». Данные в этом отчёте доступны начиная с 12 октября 2016 года.
Работать с сотнями URL в интерфейсе неудобно, поэтому список выгружают в XLS или CSV. В файле будут поля:
| Поле | Что содержит | Зачем при разборе |
|---|---|---|
updateDate | Дата обновления поисковой базы | Понять, когда страница выпала, и связать с релизом сайта |
url | Адрес страницы | Группировка по шаблону: /catalog/, ?sort=, /tag/ |
httpCode | Код ответа при последнем обходе | Сразу отсекает случаи, где проблема не в контенте, а в 3xx/4xx/5xx |
status | Статус страницы (LOW_DEMAND и другие) | Основной фильтр разбора |
target | Адрес редиректа или отображаемый в поиске адрес | Показывает, какую страницу поиск считает основной |
lastAccess | Дата последнего посещения роботом | Ключ к вопросу «почему статус не меняется после правок» |
title | Содержимое элемента title | Поиск дублей заголовков прямо в таблице |
event | Добавление или исключение из поиска | Отделить давно исключённые URL от свежих |
Коды статусов в файле
В интерфейсе статусы написаны по-русски, в выгрузке — кодами. Полезно держать таблицу под рукой: половина «непонятных» исключений на самом деле имеет точный технический диагноз, и путать их с LOW_DEMAND не нужно.
| Статус в интерфейсе | Код в файле | Что это значит |
|---|---|---|
| Малоценная или маловостребованная | LOW_DEMAND | Алгоритм решил не включать страницу в поиск |
| Исключена по Clean-param | CLEAN_PARAMS | Сработала директива Clean-param в robots.txt |
| Дубль | DUPLICATE | Страница дублирует уже представленную в поиске |
| Ошибка подключения к серверу | HOST_ERROR | Роботу не удалось установить соединение |
| Ошибка HTTP | HTTP_ERROR | При обращении к странице возникла ошибка |
| Запрещено элементом noindex | META_NO_INDEX | Метатег robots с noindex или none |
| Неканоническая | NOT_CANONICAL | Проиндексирована по адресу из rel="canonical" |
| Неглавный адрес сайта | NOT_MAIN_MIRROR | Страница относится к неглавному зеркалу |
| Статус неизвестен | OTHER | Страница известна роботу, но не участвует в поиске |
| Не удалось скачать страницу | PARSER_ERROR | Робот не получил содержимое страницы |
| Редирект | REDIRECT_NOTSEARCHABLE | Страница перенаправляет, индексируется цель |
| Запрет в robots.txt (весь сайт) | ROBOTS_HOST_ERROR | Индексирование сайта запрещено |
| Запрет в robots.txt (страница) | ROBOTS_TXT_ERROR | Индексирование страницы запрещено |
Фильтры интерфейса и лимиты отчётов
В поле фильтра по URL работают операторы, о которых мало кто помнит, — они позволяют разобрать список по шаблонам, не выгружая файл:
@tariff — URL содержит подстроку tariff ~table\|sofa — URL подходит под регулярное выражение !/tariff/* — исключить URL, начинающиеся с /tariff/ !@tariff — исключить URL, содержащие tariff !~ — исключить по регулярному выражению
У отчётов есть потолки, о которые упирается разбор крупного сайта:
- в разделе «Индексирование» отображается до 50 000 изменений страниц в поиске;
- в «Поисковых запросах» — данные по первым 3000 запросов за три месяца;
- чтобы получить статистику без ограничений, нужен файл Sitemap: тогда становится доступен архив «Все страницы».
Этот архив — самый недооценённый инструмент при массовом разборе. Он формируется только если Sitemap размещён на сайте и загружен роботом, и содержит по каждому URL поля url, status, lastAccess, fromSitemap, redirTarget, relCanonical, title, metaDescription. То есть canonical, редирект, заголовок и описание для всех известных Яндексу страниц — в одной таблице. Дубли title и «canonical ведёт не туда» вычисляются одной формулой, без краулинга сайта.
Малоценная и маловостребованная — разные причины
Статус один, а типа страниц Яндекс описывает два, и это разные диагнозы с разным лечением.
Малоценная: роботу нечего оценивать
Страница признаётся малоценной, если она дубль или не содержит видимого роботу контента. Справка предлагает конкретный список проверок:
- верны ли заголовки (
title,h1,h2) и описывают ли они содержимое; - нет ли важного контента, который дан только изображением;
- не выводится ли важный контент JS-скриптами;
- не используется ли
iframeдля вывода содержимого; - что видит робот в ответе сервера — то есть в исходном HTML, а не в браузере.
Это чинится техникой: серверный рендеринг важных блоков, вывод названия, цены и характеристик в HTML, корректные заголовки. Разбор частного случая — в материале о том, почему каталог интернет-магазина не индексируется.
Маловостребованная: контент есть, спроса нет
Здесь формулировка Яндекса точнее, чем её обычно пересказывают:
Алгоритм оценивает каждую страницу, будет ли она показана по запросам на тех позициях, где пользователь сможет её найти.
Речь не о том, есть ли у темы запросы в принципе, а о том, попадёт ли конкретная страница на заметную позицию. Страница без ошибок в HTML и с текстом может быть исключена просто потому, что по своим запросам она никогда не покажется выше конкурентов, а собственного спроса под её формулировку не существует.
Лечение здесь не техническое: менять содержимое под реальные интересы аудитории, опираясь на «Подбор слов», «Статистику поисковых запросов» и «Управление группами» в Вебмастере. Как собирать спрос и не плодить страницы под несуществующие формулировки — в руководстве по семантическому ядру.
Почему дубли попадают сюда, а не в DUPLICATE
Частый вопрос: почему явные дубли помечены как маловостребованные, хотя для дублей есть отдельный статус. Ответ из справки: содержимое страниц может незначительно различаться или меняться динамически, поэтому формально дубликатами они не признаются — но из-за схожести контента в поиск попадает только одна версия. Практический смысл: если в списке лежат почти одинаковые URL, лечить их нужно как дубли (canonical, 301, отключение генерации), а не переписывать тексты.
Что статус не значит
Четыре утверждения, которые кочуют по форумам и мешают работать:
| Миф | Как на самом деле |
|---|---|
| «Это фильтр, сайт под санкциями» | Алгоритм отбора не является ограничением. Ограничения видны отдельно, в разделе «Безопасность и нарушения» |
| «Много таких страниц — падают позиции всего сайта» | Число исключённых таким образом страниц негативно не влияет на ранжирование сайта |
| «Яндекс выделил сайту лимит страниц в индексе» | Квот на количество страниц в индексе нет |
| «Страница выпала — значит, ошибка на сайте» | Страницы могут то исчезать, то появляться: релевантность пересчитывается регулярно даже без изменений содержимого |
Есть и обратная сторона, о которой справка предупреждает прямо: если страницы удалены как маловостребованные, они всё ещё доступны и могут участвовать в поиске — алгоритм может вернуть их в выдачу. Поэтому служебные URL, которым в поиске делать нечего, надёжнее закрывать явным запретом, а не надеяться, что «Яндекс сам их не показывает».
Диагностика: шесть проверок по порядку
Порядок важен: он экономит часы. Половина случаев закрывается на первых трёх шагах, и переписывать текст не приходится вовсе.
Шаг 1. Решите, нужна ли страница в поиске
Пять вопросов, ответы на которые записываются одной строкой: какой запрос должен привести человека на URL; что он сможет сделать после перехода; есть ли у страницы отдельная задача; не отвечает ли на тот же запрос другой URL сайта; приносит ли страница продажи, заявки, трафик или поддерживает основной раздел.
Работающая формулировка интента укладывается в предложение: «Человек вводит [запрос], потому что хочет [решить задачу]; страница помогает ему сделать это через [конкретный результат]». Если предложение получается расплывчатым, у URL, скорее всего, нет собственной ценности — и правильное действие не доработка, а объединение с более сильной страницей.
Шаг 2. Проверьте ответ сервера
Индексируемая страница должна отдавать 200 OK, открываться без авторизации, быть разрешённой в robots.txt, не содержать noindex в метатеге и заголовке X-Robots-Tag, не перенаправлять робота и иметь canonical на саму себя.
curl -I https://example.com/page/ curl -I -L https://example.com/page/ # конечный URL после всех редиректов
Смотрим три вещи: код HTTP/2 200, content-type: text/html и отсутствие x-robots-tag: noindex. Если вместо 200 приходит 301, 302, 403, 404 или 500 — дальше идти незачем, сначала код ответа. Тот же результат в интерфейсе даёт инструмент «Проверка ответа сервера»: он показывает страницу глазами конкретного робота Яндекса.
Шаг 3. Посмотрите, что робот получает в HTML
Страница может выглядеть полной в браузере, а серверный ответ при этом почти пуст — типично для SPA, каталогов с динамической подгрузкой и конструкторов.
curl -L https://example.com/page/ -o page.html
В сохранённом файле ищем: H1, основной текст, название товара, цену, характеристики, ссылки на связанные страницы. Если уникальной фразы со страницы в исходном коде нет — она дорисовывается скриптами, и для важной посадочной это первая причина статуса. Надёжное решение — серверный рендеринг или предварительная генерация HTML хотя бы для первого экрана и первого набора товаров.
Шаг 4. Найдите конкурирующие URL
Ищем на сайте другую страницу с тем же ответом: одинаковые title и H1, версии со слешем и без, HTTP и HTTPS, разный регистр, сортировки и параметры, пагинацию, карточки одного товара по разным адресам. В Вебмастере для этого есть раздел «Заголовки и описания» — он показывает группы страниц с одинаковыми title и description; на крупном сайте быстрее посчитать дубли в архиве «Все страницы» по полям title и relCanonical. Подробный разбор — в материале о дублях, canonical и фильтрах.
Шаг 5. Проверьте спрос и формат выдачи
Возьмите предполагаемый запрос страницы и посмотрите: есть ли связанные формулировки в «Подборе слов»; какие запросы уже получает сайт по данным Вебмастера; что показывается в топе и какой там формат. Если в выдаче категории магазинов, статья без товаров и цен запрос не закроет. Если Яндекс по этому запросу показывает другую вашу страницу — это каннибализация, и правильное решение обычно объединение, а не доработка обеих.
Шаг 6. Посмотрите на внутренние ссылки
Страница, на которую ведёт только sitemap, выглядит изолированной. Проверьте, есть ли ссылка из категории или тематического хаба, связана ли статья с соседними материалами, понятен ли анкор и не глубже ли URL трёх-четырёх переходов от главной. Схема «Главная → Блог → 17-я страница пагинации → материал» слабее, чем «Главная → Блог → Индексация → материал». Как искать такие URL и что с ними делать — в разборе страниц-сирот и внутренней перелинковки.
Когда исключены тысячи URL
Ручной разбор здесь не масштабируется. Работает другая логика: сгруппировать список по шаблонам, проверить 10–20 адресов из каждой группы и чинить причину на уровне CMS.
Признак шаблонной проблемы: исключены 70% карточек одного типа, все страницы брендов, все категории третьего уровня, все фильтры одной CMS или все новые статьи. В этом случае бессмысленно смотреть отдельные URL — причина в шаблоне, структуре или правилах генерации адресов.
Таблица аудита
Минимальный набор колонок, которого хватает и для магазина на 200 000 URL:
| Колонка | Что записать |
|---|---|
| URL и тип страницы | Статья, товар, категория, фильтр, услуга |
| Бизнес-ценность | Высокая, средняя, низкая |
| Целевой запрос и интент | Основная формулировка; есть ли самостоятельный интент — да/нет |
| HTTP-код, robots.txt, meta robots | Из выгрузки и краулера: 200/301/404, доступна или закрыта, index или noindex |
| Canonical | Сам URL или другой адрес (поле relCanonical из архива) |
| Контент в серверном HTML | Есть или отсутствует |
| Дубль | Ссылка на основной URL |
| Внутренние ссылки | Количество и источники |
| Решение и приоритет | Улучшить, объединить, закрыть, удалить; P1–P3 |
| Дата внедрения и результат | Когда внедрено; вернулась в поиск или осталась исключённой |
Приоритеты
- P1 — критично: основные услуги, категории с продажами, популярные товары, страницы с внешними ссылками, URL, которые раньше давали трафик.
- P2 — важно: статьи внутри приоритетных кластеров, подкатегории, брендовые страницы, коммерческие фильтры со спросом.
- P3 — техническая очистка: сортировки, UTM, внутренний поиск, пустые теги, календарные архивы, тестовые URL.
P3 разбирают не поштучно, а правилом: закрыть в robots.txt, описать параметры, прекратить генерацию. Одно правило снимает десятки тысяч строк из отчёта.
Какое решение выбрать
Для каждого URL выбирается ровно одно действие. Смешивать нельзя: одновременный noindex и запрет в robots.txt — классическая ошибка, робот просто не увидит метатег.
| Ситуация | Действие | Как быстро сработает |
|---|---|---|
| Страница должна приносить трафик и заявки | Доработать под интент, усилить перелинковку, отправить на переобход | Переобход: до 3 дней в очереди, данные — до 2 недель |
| Два материала закрывают одну задачу | Оставить сильный URL, перенести полезное, 301 со слабого, обновить ссылки и sitemap | По мере обхода; смена адресов при переезде домена — больше месяца |
| Доступные дубли: сортировки, UTM, параметры отображения | rel="canonical" на основную версию, все прочие сигналы — туда же | Автоматически при обходе, ускоряется переобходом |
| Незначащие GET-параметры | Clean-param в robots.txt или «Настройка GET-параметров» в Вебмастере | Настройки в интерфейсе вступают в силу в течение недели |
| Страница нужна пользователю, но не в поиске | метатег robots со значением noindex, follow, доступ роботу оставить | При следующем обходе страницы |
| Технические зоны: админка, оформление заказа, внутренний поиск | Disallow в robots.txt | Ссылки уходят из базы робота в течение 2 недель |
| URL больше не должен открываться, есть замена | 301 на ближайшую по смыслу страницу — не на главную | Постепенно, по мере обхода |
| Страница удалена, замены нет | 404 или 410, убрать из sitemap и из меню | После повторного обхода; ускоряется инструментом удаления |
Clean-param и «Настройка GET-параметров»: что важно знать
Это два входа к одному правилу — директива в robots.txt и таблица в интерфейсе Вебмастера. У интерфейсной версии есть три особенности, о которых легко споткнуться:
- изменения вступают в силу в течение недели — не ждите реакции на следующий день;
- при противоречии настроек и robots.txt робот выполнит то правило, которое запрещает индексировать URL с параметром;
- параметры, найденные роботом самостоятельно, из списка удалить нельзя — можно только переключить значение.
Разница между инструментами закрытия — в отдельном разборе: noindex или robots.txt, и canonical для фильтров и параметров. Коротко: robots.txt управляет обходом, а не склейкой; он не передаёт приоритет другой странице и дубли не лечит.
Почему статус держится после исправления
Самая частая жалоба: страницу закрыли, удалили или доработали, а она неделями висит в списке маловостребованных. Объяснение есть в справке, и оно не про «долгую переиндексацию».
Алгоритм не выполняет повторного индексирования страниц, а проверяет тот контент страниц, который на этот момент есть в базе.
То есть алгоритм отбора работает с сохранённой копией. Пока робот не придёт заново и не увидит новый код ответа или новый контент, оценка будет пересчитываться по старым данным. Отсюда способы ускорения — все они про обход, а не про качество.
Переобход страниц
Инструмент «Индексирование → Переобход страниц» сообщает роботу о новых и обновлённых URL. Количество адресов в сутки ограничено для домена и всех поддоменов, лимит обновляется ежедневно; конкретное число справка не называет — оно показано в самом инструменте. Дальше следите за статусом заявки:
- «В очереди» — робот посетит адреса в приоритетном порядке, процесс занимает не более трёх дней, обычно быстрее;
- «Заявка обработана» — робот посетил страницу, данные обновятся в течение двух недель. Статус не означает, что страница проиндексирована: закрытая от индексирования страница в поиск не попадёт;
- «Ошибка» — робот не смог получить страницу; проверьте доступность и скорость ответа сервера и отправьте URL повторно.
На переобход не отправляют robots.txt (он и так обходится за несколько часов), favicon.ico и XML-фиды, включая Sitemap, — их переиндексирование этим инструментом не гарантируется.
Если страниц много
Для регулярной передачи больших объёмов есть два штатных механизма:
- Обход по счётчику Метрики — привязать счётчик к сайту в Вебмастере, подтвердить запрос в Метрике и включить обход: робот узнаёт о страницах, на которых установлен счётчик;
- IndexNow — разместить на сайте ключ и отправлять адреса через API:
GET https://yandex.com/indexnowдля одного URL,POSTдля нескольких. Отправлять нужно только новые, изменившиеся и удалённые страницы; для полного покрытия сайта используются Sitemap и обход по счётчику.
Ускоренное удаление из поиска
Когда страницы нужно убрать быстро, работает «Инструменты → Удаление страниц из поиска». Ограничения: до 500 адресов и до 20 префиксов для одного сайта в сутки. Робот удалит страницы, только если для них уже стоит запрет — Disallow в robots.txt для удаления по префиксу, а для отдельных URL запрет либо ответ 404, 403 или 410; иначе заявка получит статус «Отклонено». После проверки страница удаляется из выдачи в течение суток.
Обратная операция медленнее: если снять запрет, страницы вернутся в результаты поиска после того, как робот обойдёт сайт и узнает об изменениях — это может занять до трёх недель.
И отдельный приём для мусорных URL, которые продолжают числиться маловостребованными после удаления: запрет в robots.txt заставляет ссылки автоматически пропасть из базы робота в течение двух недель. Для страниц, которые нужны в поиске, так делать нельзя — робот перестанет их обходить.
Карточки, категории и фильтры
Карточки товаров
Если исключены тысячи карточек, проверяют шаблон, а не карточки: уникальны ли title и H1, попадают ли цена, наличие и характеристики в серверный HTML, заполнены ли фото и alt, настроен ли self-canonical, связана ли карточка с категорией, есть ли аналоги, не уходят ли в sitemap отсутствующие товары. Карточка из названия и фотографии проигрывает конкурентам почти всегда — подробнее в разборе SEO карточки товара.
Отдельная тема — варианты. Если каждый цвет и размер получает свой URL, спрос обычно есть только у моделей, а не у комбинаций: варианты объединяют в одной карточке, оставляя отдельные адреса там, где запросы действительно существуют. Для интернет-магазинов Яндекс дополнительно рекомендует передавать данные через YML-фид и подключение к Яндекс Товарам и Маркету — это помогает получать о страницах более полную информацию.
Отсутствующие товары не удаляют пачкой. Страницу стоит сохранить, если модель продолжают искать, на неё есть внешние ссылки, товар может вернуться или можно показать аналоги. Удалять или перенаправлять — когда товар снят окончательно, спроса нет, ссылок и трафика нет, а прямой аналог есть.
Категории
Категории выпадают из-за малого ассортимента, несоответствия названия содержимому, дублирования фильтром, одинаковых title и H1, загрузки товаров скриптами, canonical на родительский раздел, отсутствия внутренних ссылок и слишком большой глубины. Каталоги чаще всего теряют индексацию не по одной причине, а из-за конфликта сигналов: robots.txt запрещает то, что canonical объявляет основным, а sitemap отдаёт третью версию URL.
Фильтры
Фильтр имеет смысл оставлять в поиске, когда сочетание характеристик действительно ищут, ассортимент стабилен, товаров достаточно, URL постоянный, а title и H1 уникальны. Комбинации без спроса в посадочные не превращают: типичный случай — CMS сгенерировала 40 000 сочетаний, в большинстве 0–2 товара, title отличаются одним словом, а собственный спрос есть у нескольких сотен. Решение: оставить индексируемыми фильтры со спросом, для дублей настроить canonical, служебные комбинации закрыть, очистить sitemap и прекратить генерацию бессмысленных сочетаний.
Что обычно не помогает
- Дописать 2000 символов. Объём не устраняет ни дубль, ни пустой серверный HTML, ни отсутствие спроса.
- Переписать только title. Заголовок описывает страницу, но не меняет ни рендеринг, ни конкуренцию внутри сайта.
- Отправить на переобход без изменений. Робот получит ту же страницу, алгоритм — ту же оценку.
- Открыть для индексации все фильтры. Так создаются дубли, пустые категории и конкурирующие посадочные.
- Поставить noindex и одновременно закрыть URL в robots.txt. Робот не увидит метатег, потому что не сможет открыть страницу.
- Держать в sitemap закрытые и перенаправленные URL. В карте должны быть только основные индексируемые адреса с кодом 200 — см. robots.txt и sitemap.xml.
- Редиректить всё удалённое на главную. 301 должен вести на ближайшую по смыслу страницу, иначе перенаправление нерелевантно — разбор редиректов.
- Менять дату публикации без обновления содержания. Новая дата имеет смысл только после реальной актуализации.
Чек-лист перед отправкой на переобход
- URL нужен пользователям из поиска и закрывает отдельный запрос
- сервер отвечает 200 OK, страница открывается без авторизации
- robots.txt разрешает обход, нет
noindexв метатеге иX-Robots-Tag - canonical указывает на саму страницу
- основной контент присутствует в серверном HTML, а не только после JS
- на сайте нет второй страницы с тем же ответом и тем же title
- title и H1 точно описывают содержание, формат соответствует выдаче
- на страницу ведут внутренние ссылки из категории или тематического хаба
- URL есть в sitemap, в карте нет дублей и редиректов, lastmod реальный
- страница добавлена в мониторинг важных страниц
- изменения проверены на мобильном устройстве
Итог
LOW_DEMAND — не приговор странице и не пометка о нарушении, а решение алгоритма отбора, которое пересматривается почти каждый день. Причину ищут в четырёх зонах: доступность содержимого роботу, дубли и конфликтующие URL, соответствие реальному спросу, роль страницы в структуре сайта.
Важную страницу дорабатывают и связывают с кластером, дубли объединяют или канонизируют, служебные URL закрывают, удалённые отдают 404 или 410. Одну выпавшую статью разбирают руками; массовое исключение категорий, карточек или фильтров означает системную проблему — там нужен аудит шаблонов, правил индексирования, sitemap, canonical, рендеринга и внутренней структуры. И главное про сроки: после любой правки статус меняется не раньше, чем робот повторно обойдёт URL, а данные в отчётах обновятся — на это закладывают до двух недель.
Частые вопросы
Что означает статус «Малоценная или маловостребованная страница»?
Робот знает URL, но алгоритм решил не включать его в поиск: у страницы мало шансов оказаться востребованной. Типичные причины — дубль уже известной роботу страницы, отсутствие видимого роботу контента или несоответствие содержимого запросам пользователей. Это автоматический регулярный процесс, поэтому решение может измениться.
Как этот статус выглядит в выгрузке из Вебмастера?
В файле XLS или CSV в колонке status стоит код LOW_DEMAND. Рядом выгружаются поля updateDate, url, httpCode, target, lastAccess, title и event, по которым удобно фильтровать список в таблице.
Это фильтр или санкция?
Нет. Яндекс прямо пишет, что наличие таких страниц не означает нарушений и ограничений в ранжировании. Ограничения проверяются отдельно в разделе «Оптимизация сайта → Безопасность и нарушения».
Влияет ли количество малоценных страниц на позиции сайта?
Само число исключённых URL на ранжирование не влияет, и квот на количество страниц в индексе у Яндекса нет. Важен состав списка: если туда попали категории, карточки и страницы услуг, это уже потеря трафика и заявок.
Нужно ли удалять все страницы со статусом LOW_DEMAND?
Нет. Важные страницы дорабатывают, дубли канонизируют или объединяют с редиректом, технические URL закрывают от индексирования, а удалённые страницы отдают 404 или 410. Массовое удаление без разбора обычно вредит.
Поможет ли просто добавить текста?
Только если пользователю действительно не хватает информации. Объём не устраняет дубли, пустой серверный HTML, конфликт canonical и отсутствие самостоятельного спроса — это разные причины, и лечатся они разными действиями.
Что выбрать: noindex, canonical или 301?
Canonical — для доступных дублей, когда обе версии должны открываться. Noindex — для страниц, нужных пользователю, но не нужных в поиске. 301 — когда старый URL не должен открываться и есть релевантная замена.
Почему статус остался, хотя страница уже отдаёт 404 или закрыта noindex?
Алгоритм оценивает тот контент, который на этот момент есть в базе, и не переиндексирует страницу специально. Пока робот не обойдёт URL повторно и не увидит новый код ответа, ссылка продолжит числиться маловостребованной. Ускорить удаление можно запретом в robots.txt: тогда ссылки автоматически пропадут из базы робота в течение двух недель.
Сколько ждать после отправки на переобход?
Статус «В очереди» держится не более трёх дней, обычно меньше. После статуса «Заявка обработана» данные в поиске обновляются в течение двух недель, и сам статус не означает, что страница проиндексирована.
Может ли страница вернуться в поиск сама?
Да. Алгоритм проверяет страницы регулярно, почти каждый день, поэтому URL может то исчезать, то возвращаться даже без изменений содержимого. Для важной страницы лучше устранить причину, отправить на переобход и добавить её в мониторинг важных страниц.
Что делать, если исключены тысячи карточек товаров?
Разбирать не URL, а шаблон. Сгруппируйте карточки по типу, категории, бренду и наличию, проверьте 10–20 адресов из каждой группы и ищите повторяющуюся причину: пустой серверный HTML, одинаковые title, canonical на категорию, отсутствие цены и характеристик в коде.
Чем инструмент «Настройка GET-параметров» отличается от Clean-param?
Это два способа задать одно правило: директива Clean-param в robots.txt и таблица параметров в интерфейсе Вебмастера. Настройки в интерфейсе вступают в силу в течение недели, а при противоречии с robots.txt робот выполнит то правило, которое запрещает индексировать URL с параметром.
Источники
- Малоценные или маловостребованные страницы — справка Яндекс Вебмастера
- Страницы в поиске: фильтры, выгрузка и коды статусов
- Почему страницы исключены из поиска
- Расширенная статистика по сайту: архив «Все страницы»
- Переобход страниц и статусы заявки
- Как удалить страницы из поиска: лимиты и статусы
- Настройка GET-параметров
- Поддержка протокола IndexNow
- Индексирование сайта с помощью счётчика Метрики
Все формулировки и числовые ограничения сверены со справкой Яндекс Вебмастера 30 июля 2026 года.
Разбор индексации
Разобрать исключённые страницы вашего сайта
Возьму выгрузку «Страниц в поиске», сгруппирую исключённые URL по причинам и верну таблицу с решением по каждой группе: доработать, объединить, канонизировать, закрыть или удалить — с приоритетами по влиянию на трафик и заявки.
Получить разбор