Техническое SEO

Куда тратится обход сайта: 420 закрытых страниц

Робот исправно ходил по сотням адресов, которые сайт сам пометил «не индексировать», и ни разу не зашёл на две страницы из главного меню. Разбор собственного отчёта Search Console и проверки, которые стоит сделать на своём сайте.

Худшая новость в отчёте об индексации никогда не написана в нём цифрой. Она там, где цифры нет.

Двадцать первого августа 2026 мы смотрели Search Console собственного сайта. Проиндексировано 262 страницы, не проиндексировано 529. Первое, что хочется сделать с таким отчётом, — взяться за самую большую кучу. Самая большая куча выглядела так:

Причина Страниц
исключено тегом noindex 420
заблокировано в robots.txt 25
обнаружено, но не просканировано 37
просканировано, не проиндексировано 24
ошибка 404 11
страница с переадресацией 10
альтернативная каноническая 2

Четыреста двадцать страниц с noindex. Выглядит как катастрофа и требует немедленных действий. На самом деле это самая здоровая строка во всём отчёте: сайт сам закрыл эти адреса, робот увидел запрет и подчинился. Система работает как задумано.

Проблема лежала двумя строками ниже.

Тридцать семь адресов, до которых робот не дошёл

В категории «обнаружено, но не просканировано» оказались страница «О нас» и страница портфолио. Обе — из главного меню. То есть Google знал об их существовании и ни разу не потратил на них запрос.

Рядом он исправно обходил 420 адресов, помеченных «не индексировать».

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

Откуда он их вообще берёт

Ответ нашёлся в одном файле. У нас есть служебная страница — карта услуг, полный перечень всего, что есть на сайте. На ней 296 ссылок, и весит она 887 КБ.

Для робота это самая удобная точка входа: одна страница, с которой видно всё. Он её обходит, забирает оттуда сотни адресов и начинает ходить по ним — включая те, что закрыты от индексации. Обход тратится, индекс не пополняется.

Важно, что сама страница не ошибка. Ошибка — считать, что «пусть робот видит всё» бесплатно. Каждая ссылка, которую вы показываете, — это заявка на обход, и робот выполняет их в своём порядке, а не в вашем.

Карта сайта, противоречившая самим страницам

Четырьмя днями раньше, 17 августа, нашлась вещь хуже неравномерного распределения: четыре страницы лежали в карте сайта и одновременно отдавали noindex.

Это прямо противоречивые указания. Карта говорит: «вот адрес, пожалуйста, обойди». Страница говорит: «меня не индексировать». В интерфейсе Search Console такой адрес оседает в ошибках, и обоснованно — сайт сам себе противоречит.

Причина оказалась банальной и поучительной. У нас есть правило: раздел, в котором меньше трёх страниц, не индексируется — слишком пустой, чтобы быть полезным. Правило нормальное. Но порог «три» был записан константой внутри кода страницы, а сборка карты сайта о нём не знала и добавляла туда всё подряд.

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

Одиннадцать страниц, которых больше нет

Отдельная строка отчёта — 404. Одиннадцать адресов, которые когда-то работали.

Часть из них — следствие обычной уборки. Мы убирали числовые суффиксы из нескольких адресов: было …/consent-mode-v2-4, стало …/consent-mode-v2. Новый адрес работает, старый проверить забыли. Ещё несколько страниц переехали в другой раздел — тоже без переадресации со старого места.

Здесь работает правило, которое легко сформулировать и легко забыть: проверять нужно не то, что новый адрес открывается, а то, что старый ведёт на новый. Первое очевидно и проверяется само собой. Второе никто не замечает, пока не посмотрит в отчёт.

Вторая часть 404 интереснее. Это адреса вида /en/… с украинскими написаниями — страницы, которые когда-то существовали на всех языках, а потом остались только на украинском. У нас 52 страницы из двухсот с лишним имеют только одну языковую версию: перевода нет, а машинный мы ставить не стали. О том, как языковые версии ломаются изнутри, есть отдельный разбор. Google запомнил старые адреса и ещё долго будет по ним ходить.

Как посмотреть то же самое у себя

1. Раскройте отчёт индексации полностью. Search Console, раздел «Индексирование страниц». Смотрите не на общую цифру, а на перечень причин, и читайте его снизу вверх — от малых категорий к большим. Самое важное почти всегда в «обнаружено, но не просканировано»: там лежат страницы, которые робот знает и игнорирует.

2. Сверьте карту сайта с состоянием самих страниц. Самая простая ручная проверка:

curl -s https://ваш-сайт.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' | head -50 \
  | while read u; do
      echo "$(curl -s "$u" | grep -c 'noindex')  $u"
    done

Любая единица в первой колонке — страница, противоречащая собственной карте.

Если адресов много, это стоит автоматизировать. Мы держим в проекте отдельный скрипт, который обходит все адреса из всех карт под видом Googlebot и проверяет четыре вещи: код ответа, запрет в robots.txt, noindex в метатегах и в заголовке X-Robots-Tag, а также canonical. Последнее про заголовок — не мелочь: noindex можно отдать ответом сервера, и в исходном коде страницы его не будет видно вообще.

3. Найдите свою страницу-каталог. Ту, с которой видно всё. Посчитайте на ней ссылки и посмотрите, сколько из них ведут на адреса, которые вы и не собирались индексировать.

4. Проверьте старые адреса, а не новые. Составьте перечень всего, что вы переименовывали или переносили за последний год, и пройдитесь по старым адресам. Каждый должен отвечать 301, а не 404.

Три ловушки, на которых мы потеряли время

Это часть, которой обычно нет в статьях, а она самая полезная.

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

Не замеряйте всё сразу в много потоков. Обход трёхсот адресов в шестнадцать потоков с таймаутом двадцать секунд дал нам три ложные тревоги подряд: самые тяжёлые страницы отдают по 630–670 КБ и не успевают, а оборванный HTML читается как «страница без canonical и с noindex». Либо меньше потоков, либо больше таймаут.

Ошибка 502 во время обхода — часто не дефект сайта. Если вы только что выкатили обновление, контейнер мог перезапускаться ровно в этот момент. Проверяйте повторно, прежде чем заводить задачу.

Общее из всех трёх: измерительный инструмент ошибается чаще, чем то, что он измеряет. Прежде чем поверить в тревожный результат, проверьте подозрительный адрес поодиночке, руками.

Честные границы

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

Исправление распределения обхода не добавляет позиций и не приносит трафика само по себе. Оно делает одно: убирает причины, по которым страница, способная работать, вообще не попадает в индекс. Дальше всё равно решает содержание страницы и спрос на то, что на ней написано.

И ещё одно, что стоит сказать прямо: страница с noindex — это нормально. Служебные разделы, пустые категории, дубли фильтров закрывать нужно. Плохо не то, что их много, а то, что робот тратит на них время, которое должен был потратить на другое. Разницу видно только в отчёте — и только если читать его дальше первой цифры.

Теги

SEO

Вам понравилась статья?

Ваше мнение помогает нам создавать лучший контент

Поделитесь с друзьями

Нашли что-нибудь полезное?

Помогите другим узнать это — поделитесь статьей в социальных сетях

Спасибо, что помогаете нам расти

Основатель LIONEX

Владислав Чистяков

Пишет о том, что делает руками: интернет-магазины на OpenCart, приложения на Next.js, интеграции и скорость сайтов. В статьях — замеры и проверки, которые читатель может повторить на своём проекте, а не общие советы. Коммерческая разработка с 2015 года.

Вопросы

Частые вопросы

Ответы на популярные вопросы по теме

С какого размера сайта об обходе вообще стоит думать?

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

Можно ли вместо noindex закрыть страницы в robots.txt?

Это разные вещи, и путать их дорого. Запрет в robots.txt не пускает робота на страницу — поэтому он не увидит и тег noindex на ней. Такой адрес может остаться в выдаче без описания. Если цель — убрать из индекса, нужен именно noindex и открытый доступ. Если цель — не тратить обход, тогда robots.txt.

Большое количество страниц с noindex — это плохо?

Само по себе нет. Служебные разделы, пустые категории и дубли фильтров закрывать правильно. Плохо другое: когда робот тратит на них время, которое должен был потратить на страницы, ждущие индексации. Смотреть надо не на количество, а на то, что лежит в категории «обнаружено, но не просканировано».

Что делать со старыми адресами после смены структуры?

Ставить переадресацию 301 со старого адреса на новый — и проверять именно её. Самая частая ошибка в том, что проверяют, открывается ли новый адрес. Он открывается всегда. Вопрос в том, куда ведёт старый, и ответ на него виден в отчёте об ошибках 404 через несколько недель.

Получайте лучшие статьи на почту

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

Мы уважаем вашу конфиденциальность. Отписаться можно в любой момент.

Ещё в блоге

Похожие статьи

Мы потеряли собственный магазин вместе с доменом: что об этом знает веб-архивТехническое SEO

Мы потеряли собственный магазин вместе с доменом: что об этом знает веб-архив

17 сентября 2026 мы пересчитали по веб-архиву, как выглядела потеря собственного магазина вместе с доменом: 2 378 снимков главной в марте 2022, первый 301 первого апреля, последний снимок нашего содержимого 18 мая. Показываем, что из архива восстанавливается, а что нет.

Читать дальше
IndexNow отвечал 200, а страницы не поданы: 6 файлов вместо 867 адресовТехническое SEO

IndexNow отвечал 200, а страницы не поданы: 6 файлов вместо 867 адресов

Со 2 августа по 3 сентября 2026 наш скрипт IndexNow подавал в Bing шесть адресов файлов карты сайта вместо страниц, и на каждую подачу приходило «успешно». Разбираем, почему код 200 ничего не доказал и как за 15 минут проверить, что именно подает ваш модуль.

Читать дальше
Первый экран прыгает: как мы искали сдвиг от шрифта и что не сработалоБыстродействие сайта

Первый экран прыгает: как мы искали сдвиг от шрифта и что не сработало

17.08.2026 аудит показал CLS 0,2283 на десктопной главной нашего сайта. Причиной оказался шрифт: единица ch в абзаце и наклоненная декоративная полоса. Разбираем, какие советы по замерам не помогли, что дало 0,0056 и как проверить свой сайт.

Читать дальше