Сканирование (краулинг)

Происхождение и история термина

Английское crawl — «ползать». Отсюда crawler («ползун») и родственные метафоры spider («паук») и spider trap («ловушка для паука») — программа «ползёт» по паутине ссылок World Wide Web. В русском языке закрепились три варианта: калька «краулинг», термин «сканирование» (так переведён интерфейс Google Search Console, отчёт «Статистика сканирования» ^[16]) и термин «обход», который использует Яндекс: «Скорость обхода», «Статистика обхода» ^{[19; 22]}.

Ключевые вехи:

Уже в 1998 году Брин и Пейдж отмечали: «Crawling is the most fragile application since it involves interacting with hundreds of thousands of Web servers […]» («Сканирование — самая хрупкая часть системы, поскольку предполагает взаимодействие с сотнями тысяч веб-серверов […]») ^[2]. Сегодня обход дополнился протоколами уведомлений, такими как IndexNow ^[17], и рендерингом: Google при сканировании отображает страницу и выполняет JavaScript в актуальной версии Chrome ^[8].

Суть и механизм

Определение в учебнике

Классический учебник по информационному поиску определяет: «Web crawling is the process by which we gather pages from the Web, in order to index them and support a search engine» («Веб-краулинг — процесс, при котором мы собираем страницы из веба, чтобы проиндексировать их и обеспечить работу поисковой системы») ^[1]. Цель — быстро и эффективно собрать как можно больше полезных страниц вместе со структурой ссылок между ними ^[1]. Обзор Олстона и Найорка подчёркивает, что лишь на первый взгляд это простое применение обхода графа в ширину: на деле приходится решать множество инженерных и стратегических задач ^[3].

Цикл обхода

Учебник Manning et al. описывает типовую архитектуру краулера из пяти модулей: очередь URL (URL frontier), разрешение DNS, загрузка по HTTP, разбор страницы (извлечение текста и ссылок) и устранение дубликатов ^[1]. Ниже — цикл по этой модели; это учебная схема, а не описание конкретного Googlebot или робота Яндекса.

1. Источники адресов. Ссылки на уже известных страницах, файлы Sitemap, ручные запросы владельца, уведомления (IndexNow), у Яндекса — также данные Метрики ^{[8; 18]}.
2. Очередь (frontier). Адреса, ожидающие загрузки, упорядочиваются по приоритету и с учётом вежливости к хосту ^[1].
3. Проверка robots.txt. Правила проверяются непосредственно перед загрузкой, а не при постановке в очередь: адрес может пролежать в очереди дни и недели, а файл за это время измениться ^[1].
4. DNS. Определяется сервер, с которого нужно скачать страницу ^[1].
5. HTTP-запрос и ответ. Сервер возвращает код ответа, заголовки и содержимое ^{[1; 10]}.
6. Разбор. Из страницы извлекаются текст и ссылки; текст передаётся на индексирование ^[1].
7. Фильтрация новых адресов. Относительные ссылки приводятся к полному виду, проверяется, не встречался ли уже такой адрес; новые адреса возвращаются в очередь ^[1].

Обнаружение URL

Google прямо пишет, что центрального реестра всех веб-страниц не существует, поэтому поисковик постоянно ищет новые и обновлённые страницы; этот процесс он называет «URL discovery» — обнаружение URL ^[8]. Яндекс перечисляет способы сообщить роботу о страницах: файл Sitemap, ссылки с других ресурсов, инструмент «Переобход страниц» в Вебмастере, счётчик Яндекс Метрики и протокол IndexNow ^[18]. При этом обход по внешним ссылкам занимает время и, как предупреждает Яндекс, не гарантирует, что робот обойдёт все страницы ^[18].

Приоритет и вежливость

Очередь краулера решает две задачи одновременно. В модели учебника «передние» очереди отвечают за приоритет, «задние» — за вежливость ^[1]. Приоритет страницы, по мнению авторов, должен зависеть и от частоты её изменения, и от качества: иначе краулер будет без конца перекачивать спам-страницы, которые меняются постоянно ^[1]. Вежливость означает, что к одному хосту открыто не больше одного соединения, а между запросами выдерживается пауза. Эвристика учебника — пауза на порядок больше времени последней загрузки с этого хоста ^[1].

Учебник называет два обязательных свойства краулера. Устойчивость (robustness): в вебе есть «ловушки для пауков» — генераторы страниц, сбивающие краулер с пути, причём часть ловушек появляется непреднамеренно из-за ошибок разработки сайта ^[1]. Вежливость (politeness): у серверов есть явные и неявные правила допустимой частоты визитов, и краулер обязан их соблюдать ^[1].

Сколько и как часто

Google алгоритмически определяет, какие сайты сканировать, как часто и сколько страниц загружать с каждого; найденные страницы сканируются не все — часть закрыта владельцем, часть доступна только после входа в аккаунт ^[8]. Для больших сайтов Google описывает модель краулингового бюджета — множества URL, которые Google «может и хочет» просканировать ^[9]. «Может» — это лимит пропускной способности (crawl capacity limit), ограничивающий нагрузку на сервер. «Хочет» — спрос на сканирование (crawl demand): его определяют «воспринимаемый объём» сайта (известные Google адреса), популярность URL и необходимость заметить изменения (staleness) ^[9]. Подробнее — в статье «Краулинговый бюджет».

У Яндекса скорость обхода — число запросов в секунду, которое робот отправляет на сайт. Оптимальную скорость рассчитывают алгоритмы, а фактическая может отличаться от заданной владельцем с учётом информации о сайте, которой располагает Яндекс ^[19].

Для Google есть ориентир верхней границы: для большинства сайтов Googlebot в среднем не должен обращаться чаще одного раза в несколько секунд ^[11]. Это ограничение вежливости, а не обещание регулярных визитов.

Протокол и ответ сервера

Краулеры и сборщики Google поддерживают HTTP/1.1 и HTTP/2, сжатие gzip, deflate и Brotli, а также условные запросы с заголовками ETag/If-None-Match и Last-Modified/If-Modified-Since по стандарту HTTP-кэширования ^[12]. При сканировании для Поиска Googlebot обрабатывает первые 2 МБ файла поддерживаемого типа и первые 64 МБ PDF-файла (данные страницы Googlebot, обновлённой 03.02.2026) ^[11]. Робот Яндекса передаёт заголовок Accept-Encoding: gzip,deflate ^[24].

Реакция Google на коды ответа описана в его документации ^[10]:

Яндекс рекомендует код 429 как способ сообщить, что сервер испытывает затруднения с нагрузкой: робот сократит число обращений ^[20]. Подробнее о кодах — в статье «Коды ответа сервера».

Как краулер запрашивает robots.txt: стандарт, Google и Яндекс

Синтаксис директив — в статье «robots.txt». Здесь важно различать стандарт и практику Google и Яндекса.

Стандарт RFC 9309 ^[7]:

• краулеру следует пройти не меньше пяти редиректов подряд (разд. 2.3.1.2);
• при кодах 4xx файл считается недоступным, и краулер может обращаться к любым ресурсам (разд. 2.3.1.3);
• при кодах 5xx и сетевых ошибках краулер обязан считать сайт полностью закрытым; если состояние длится достаточно долго (в стандарте пример — 30 дней), он может считать файл недоступным или продолжать использовать кэшированную копию (разд. 2.3.1.4);
• кэшированную версию не следует использовать дольше 24 часов, если файл доступен (разд. 2.4);
• предел разбора файла — не меньше 500 КиБ (разд. 2.5).

Стандарт подчёркивает, что эти правила — не механизм авторизации доступа: это просьба к краулерам, а не защита ^[7].

Как это реализуют поисковики:

Практический вывод: ошибка сервера на robots.txt у Google может на время остановить обход всего сайта, а у Яндекса — привести к обратному: сайт будет считаться открытым для индексирования ^{[25; 26]}.

Рендеринг

Google при сканировании отображает страницу и выполняет найденный JavaScript в актуальной версии Chrome ^[8]. Поэтому для краулера важен не только HTML, но и ресурсы, без которых страница не отображается. Подробнее — в статьях «Рендеринг страниц» и «JavaScript SEO».

Где сканирование заканчивается

Сканирование завершается получением содержимого. Код 2xx, по формулировке Google, «doesn't guarantee indexing» — не гарантирует индексирования ^[10]. Яндекс указывает, что после обхода страницы могут появиться в поиске в течение двух недель, но точного срока не обещает ^[18]. Дальнейшие этапы — в статье «Индексация».

Виды и классификации

По цели обхода (классификация Google). Отчёт «Статистика сканирования» делит запросы на «Обнаружение» — URL сканируется впервые — и «Обновление» — повторное сканирование известной страницы ^[16]. В отраслевой речи второй вид называют переобходом.

По инициатору (обобщение на основе документации). Не официальная классификация поисковиков, а удобная схема:

• плановый (алгоритмический) обход — поисковик сам решает, что и когда скачивать ^{[8; 19]};
• обход по запросу владельца — «Переобход страниц» в Яндекс Вебмастере, инструмент «Проверка URL» в Search Console ^{[14; 18]};
• обход по уведомлению — файлы Sitemap и протокол IndexNow ^{[14; 17; 18]}.

По стратегии (научная классификация). Олстон и Найорк различают:

• пакетный краулинг — обход периодически останавливается и начинается заново, и инкрементальный — непрерывный процесс, который «никогда не начинается сначала» ^[3]. По Чо и Гарсиа-Молине, инкрементальный краулер может заметно повысить «свежесть» коллекции ^[30];
• универсальный (широкий) краулинг, цель которого — охват всех типов контента, и тематический, или фокусированный, при котором нужными считаются только страницы по заданным темам ^[3]. Идею фокусированного краулера предложили Чакрабарти и соавторы: он выборочно ищет страницы, релевантные заданному набору тем, используя классификатор ^[4].

Российский пример научной постановки — адаптивный краулер Печникова и Чернобровкина для поиска внешних гиперссылок на множестве однотематических сайтов: его поведение сформулировано как задача о многоруком бандите ^[6]. Это исследовательская модель, а не описание работы коммерческих поисковиков.

По типу клиентов Google. Google делит свои программы на обычные краулеры, краулеры особого назначения и сборщики, запускаемые пользователем ^[12]. Подробнее — в статье «Поисковый робот».

Как применяется на практике

Помочь обнаружению

• Внутренние ссылки и Sitemap. Ссылки и карты сайта — основные каналы обнаружения у обоих поисковиков ^{[8; 18]}. Google советует при большом числе адресов отправлять Sitemap ^[14].
• Ручной запрос. В Яндексе — «Переобход страниц» ^[18]. В Google — «Проверка URL»: на отдельные URL действует квота, повторные запросы одного URL не ускоряют сканирование, а само сканирование может занять от нескольких дней до нескольких недель ^[14].
• IndexNow. Протокол позволяет автоматически сообщать Яндексу о новых, изменённых и удалённых страницах ^[18]. По документации IndexNow, в одном POST-запросе можно передать до 10 000 URL, а участвующие поисковики автоматически обмениваются полученными адресами; ответ 200 означает лишь, что URL получен ^[17].

Не тратить обход впустую

Типичная причина лишних запросов — дубли адресов с GET-параметрами. Яндекс рекомендует директиву Clean-param, указывающую роботу нужный URL среди дублей ^[20]. Google в руководстве для больших сайтов советует устранять дубли, чтобы сканирование шло по уникальному содержимому, а не по уникальным адресам ^[9]. Отдельный случай — фасетная навигация (фильтры каталога): по документации Google, она может порождать бесконечные пространства URL из-за огромного числа сочетаний фильтров; краулер тратит время на бесполезные адреса, и новые полезные страницы обнаруживаются медленнее ^[28]. Google предлагает закрывать такие URL в robots.txt или передавать фильтры во фрагменте адреса (после #), который его поиск обычно не сканирует ^[28]. Подробнее — в статьях «Дубли страниц», «Директива Clean-param», «Цепочка редиректов», «Пагинация».

Снизить нагрузку

Google предупреждает: если Googlebot несколько дней подряд получает 500, 503 или 429 по одному URL, адрес может быть удалён из индекса ^[13]. Яндекс отдельно отмечает, что поддомены он считает отдельными сайтами, поэтому нагрузка на сервер может вырасти в несколько раз, и советует начать с анализа логов сервера ^[20].

Типовые сценарии

1. Интернет-магазин с фасетными фильтрами. Каждая комбинация фильтров порождает новый URL, и робот тратит запросы на варианты одной страницы. Решения из документации: Clean-param и Disallow для Яндекса ^[20], закрытие фасетных URL в robots.txt или фильтры во фрагменте адреса для Google ^[28].
2. Сервер отвечает 5xx на запрос robots.txt. Стандарт RFC 9309 предписывает краулеру считать весь сайт закрытым ^[7]. Google первые 12 часов не сканирует сайт, затем до 30 дней работает по последней удачной копии файла, а без копии считает ограничений нет ^[25]. Яндекс учитывает robots.txt только при ответе 200 OK, иначе считает сайт открытым ^[26].
3. Новый раздел без внутренних ссылок и вне Sitemap. Поисковику неоткуда узнать адреса: центрального реестра страниц нет ^[8]. Нужны ссылки, Sitemap или уведомление ^[18].

Как измерить или проверить

Яндекс Вебмастер → Индексирование → Статистика обхода. График «История обхода» показывает число обойдённых страниц с учётом кода ответа сервера; списки «Последние изменения» и «Все страницы» выводят до 50 000 строк ^[22]. Отчёт фиксирует смену кода ответа, но не смену контента; данные обновляются ежедневно в течение шести часов после визита робота и доступны с 20 февраля 2017 года ^[22]. Рядом — «Скорость обхода» и «Анализ robots.txt» ^[23]. Инструмент «Проверка ответа сервера» показывает, доступна ли страница роботам Яндекса и какой HTTP-код она отдаёт; робота можно выбрать из списка. Яндекс оговаривает, что ответ инструменту может отличаться от реального ответа роботу, потому что запрос идёт с другого IP-адреса ^[31].

Google Search Console → Статистика сканирования. Показывает общее число запросов на сканирование, общий размер скачивания и среднее время ответа; разбивки — по ответу, типу файла, цели («Обнаружение» / «Обновление») и типу Googlebot ^[16]. Блок «Статус хоста» оценивает доступность robots.txt, DNS-преобразование и подключение к серверу за последние 90 дней. Отчёт доступен только для ресурсов корневого уровня (доменных и с префиксом URL) ^[16]. Статусы отдельных адресов, в том числе «Обнаружена, не проиндексирована», — в «Отчёте об индексировании страниц» ^[27].

Логи сервера фиксируют запросы к сайту, включая запросы роботов; с их анализа Яндекс советует начинать поиск источника нагрузки ^[20]. Перед анализом стоит убедиться, что запрос действительно сделан роботом поисковика: Яндекс описывает проверку обратным и прямым DNS-запросом ^[24]. Подробнее — в статьях «Лог-файлы сервера» и «Поисковый робот».

Рабочие показатели практиков (не официальные метрики поисковиков): запросы робота в сутки; распределение ответов 2xx/3xx/4xx/5xx; среднее время ответа; соотношение «Обнаружения» и «Обновления»; задержка между публикацией страницы и первым визитом робота. Рабочая формула:

Доля ошибочных ответов = (число ответов 4xx + 5xx) / все запросы робота × 100 %.

Ошибки, ограничения и спорные вопросы

Миф «просканировано — значит, в индексе». Ответ 2xx не гарантирует индексирования ^[10], а этапы поиска проходят не все страницы ^[8]. В Search Console есть отдельный статус «Страница просканирована, но пока не проиндексирована» ^[27].

Миф «robots.txt убирает страницу из поиска». Google пишет, что robots.txt нужен прежде всего, чтобы не перегружать сайт запросами, и «is not a mechanism for keeping a web page out of Google» («не является механизмом, позволяющим убрать страницу из Google»). Закрытый URL может показываться в результатах без описания; чтобы исключить страницу, нужен noindex или защита паролем ^[15]. При этом noindex сработает, только если страница не закрыта в robots.txt: иначе краулер не скачает её и не увидит директиву ^[29]. Подробнее — в статьях «noindex» и «Индексация».

Миф «Crawl-delay снижает нагрузку». Яндекс не учитывает директиву с 22 февраля 2018 года и предлагает настройку «Скорость обхода» ^[21]; Google её не поддерживает ^[25].

Почему страница не сканируется: статус «Обнаружена, не проиндексирована». В «Отчёте об индексировании страниц» Search Console этот статус означает, что Google нашёл страницу, но ещё не сканировал её. Как правило, Google хотел просканировать URL, но ожидал, что это перегрузит сайт, и перенёс сканирование; поэтому дата последнего сканирования в отчёте пуста ^[27]. Типичные причины, по которым страница вообще не сканируется:

• адрес закрыт в robots.txt — в отчёте это отдельный статус «Доступ к URL заблокирован в файле robots.txt» ^[27];
• поисковик не знает адреса: на страницу нет ссылок, её нет в Sitemap, уведомление не отправлялось ^{[8; 18]};
• страница доступна только после входа в аккаунт ^[8];
• обход сдерживается лимитом нагрузки: сервер медленно отвечает или отдаёт 429 и 5xx ^{[9; 10]};
• адрес теряется среди множества малоценных URL, например фасетных ^[28].

Ошибки, которые мешают обходу:

• держать 503 неделями — Google советует ограничиваться часами или 1–2 днями ^[13];
• отдавать 5xx на robots.txt: у Google это остановка обхода на первые 12 часов, у Яндекса сайт считается открытым ^{[25; 26]};
• закрывать CSS и JavaScript, нужные для отображения: Google рендерит страницы при сканировании ^[8];
• отправлять один URL на переобход многократно — это не ускоряет сканирование ^[14].

Ограничения. Обход по внешним ссылкам требует времени и не гарантирует обхода всех страниц ^[18]. Некоторые роботы Яндекса не учитывают ограничения robots.txt, заданные для всех роботов (User-agent: *), — для них нужны отдельные правила ^[24].

Спорный вопрос: нужен ли небольшому сайту краулинговый бюджет. Google адресует руководство сайтам с 1 млн+ уникальных страниц, меняющихся примерно раз в неделю, и сайтам от 10 000 страниц с ежедневными изменениями, оговаривая, что цифры — «rough estimate», грубая оценка ^[9]. На Яндекс эти пороги переносить нельзя: в его Справке о скорости обхода ^[19] такой модели нет.

Научное наблюдение. По итогам работы Чо и Гарсиа-Молины (VLDB 2000) эксперименты и теоретический анализ показали, «surprisingly at the time» («неожиданно для того времени»), что политика, выделяющая больше ресурсов часто меняющимся объектам, не обязательно даёт лучший результат (performance) ^[5]. Это вывод исследования, а не описание текущих алгоритмов Google или Яндекса.

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

Связанные термины

• Поисковый робот
• Индексация
• Краулинговый бюджет
• robots.txt
• Карта сайта (sitemap.xml)
• Коды ответа сервера
• Лог-файлы сервера
• Рендеринг страниц
• Яндекс Вебмастер
• Google Search Console