SEO в 2020-е годы

Практически в каждом разговоре о краулинговом бюджете рано или поздно появляется фраза вроде «у Google есть N запросов в сутки на сайт». Обычно за ней следует конкретная цифра, которую кто-то когда-то где-то видел. Но фиксированного числа запросов для каждого сайта не существует.

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

Как уже говорилось в предыдущей главе, Google описывает эти факторы через два понятия: crawl capacity (способность сайта выдерживать нагрузку от поискового робота) и crawl demand (потребность поисковой системы обходить страницы сайта). Именно их сочетание объясняет, почему одна и та же проблема почти незаметна для сайта на пятьсот страниц и становится серьёзной для сайта на пять миллионов URL.

Два фактора вместо фиксированного лимита

Crawl capacity показывает, какую нагрузку сайт способен выдерживать при обращениях поискового робота. Здесь учитываются прежде всего скорость и стабильность ответов сервера. Если сайт нормально отвечает на запросы, Google может увеличивать интенсивность обхода. Если ответы становятся медленными или сервер начинает возвращать ошибки 5xx либо статус 429, частота запросов может быть снижена.

В документации Google этот механизм называется crawl capacity limit, или hostload: это ограничение на объём нагрузки, которую поисковый робот создаёт при обходе сайта. В опубликованных Google материалах 2026 года отдельно подчёркивается, что новый сайт начинает с консервативного значения по умолчанию, а дальнейшее увеличение допустимой нагрузки зависит не только от технического состояния сайта, но и от наличия потребности в более интенсивном обходе. Поэтому возраст домена, размер компании или известность бренда сами по себе не дают сайту повышенного лимита.

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

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

Фактический объём обхода складывается из взаимодействия этих двух факторов. В SEO для этого обычно используют выражение «краулинговый бюджет», хотя в документации Google основной акцент сделан именно на crawl capacity и crawl demand. Это не фиксированное число запросов, которое сайт получает на сутки, а изменяющийся баланс между возможностями инфраструктуры и потребностью поисковой системы в обработке URL.

Ещё одна деталь из свежей редакции документации

Стоит отдельно упомянуть менее очевидное уточнение из той же редакции документации от июля 2026 года: ограничение crawl capacity (пропускной способности обхода) является общим для всех поисковых роботов Google, а не устанавливается отдельно для каждого из них.

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

Иными словами, crawl capacity относится к инфраструктуре сайта в целом, а не к персональной квоте одного Googlebot. Растущая активность других роботов, в том числе собирающих данные для систем искусственного интеллекта, тоже может создавать нагрузку на эту инфраструктуру. К этому вопросу книга вернётся отдельно.

Почему это вообще не проблема (для большинства сайтов)

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

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

На каталоге с миллионами товаров ситуация уже другая. Та же фасетная навигация способна создать URL-пространство, на порядки превышающее количество действительно значимых страниц. В результате поисковому роботу приходится тратить ресурс обхода на адреса вроде «цвет=синий&размер=42&скидка=да», которые никогда не станут самостоятельными посадочными страницами, вместо того чтобы быстрее добраться до действительно важных URL, например карточки нового товара.

Именно в этом проявляется практический смысл взаимодействия crawl capacity (способности сайта выдерживать нагрузку от поискового робота) и crawl demand (потребности поисковой системы обходить страницы сайта). Google описывает результат этого взаимодействия как набор URL, которые Googlebot может и хочет обходить. «Может» связано с доступной ёмкостью, а «хочет» с потребностью в обходе конкретных страниц.

При этом большое количество URL само по себе не делает их более приоритетными. Если поисковой системе практически не нужны тысячи страниц, созданных комбинациями фильтров, их количество не увеличивает спрос на обход. Но доступные для обхода URL всё равно могут расходовать часть ресурса, который мог бы быть направлен на более важные страницы. Именно поэтому на крупных сайтах управление URL-пространством становится самостоятельной SEO-задачей. обхода.

Что реально расходует бюджет впустую

В технических аудитах чаще всего повторяется один и тот же набор источников избыточного обхода, который не приносит сайту заметной пользы. Это фасетная навигация и параметры сортировки и фильтрации, создающие большое количество URL с почти одинаковым содержимым; внутренний поиск по сайту, страницы которого случайно стали доступными для обхода и индексации; дубли, возникающие из-за нескольких URL одного и того же товара или материала; постраничная навигация в бесконечных лентах, где количество страниц может расти практически без ограничений.

Ни один из этих случаев сам по себе не означает ошибку разработчиков. Каждый механизм может решать вполне понятную пользовательскую задачу. Проблема появляется при большом количестве таких URL. То, что для пользователя выглядит как удобный фильтр или сортировка, для поискового робота становится ещё одним адресом в URL-пространстве сайта. Если таких адресов тысячи или миллионы, они начинают конкурировать за тот же ресурс обхода, который нужен действительно важным страницам.

Экономика масштаба, а не абстрактный лимит

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

Для сайта на пять миллионов URL ситуация принципиально другая. Здесь уже важно, какие страницы поисковый робот действительно успевает обходить. Если значительная часть ресурса уходит на параметры, фильтры, дубли и другие малозначимые URL, важные страницы могут дольше оставаться необойденными и, соответственно, не переходить к следующим этапам обработки. В том числе это может проявляться в статусе «Discovered — currently not indexed».

Главный практический вывод этой главы заключается в следующем: краулинговый бюджет — не фиксированный лимит, который нужно однажды выяснить и затем попытаться увеличить. Он складывается из двух факторов: насколько быстро и стабильно сайт способен обрабатывать запросы поискового робота и насколько разумно организовано его URL-пространство.

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

О том, как избыточное URL-пространство формируется из параметров, фильтров, сортировки и пагинации и как управлять им уже на уровне архитектуры сайта, а не только выявлять последствия, — в следующей главе.

У одной карточки товара в интернет-магазине может быть не один URL, а десятки и даже сотни. Сортировка по цене, популярности или новизне. Фильтры по цвету, размеру, бренду и наличию. Постраничная навигация для каждой комбинации параметров. Параметр сессии, который CMS добавляет автоматически. Такое множество адресов обычно не создаётся намеренно. Оно становится результатом вполне разумных по отдельности решений, связанных с устройством каталога и удобством интерфейса.

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

Именно поэтому URL-структуру крупного сайта нельзя рассматривать только как вопрос удобства навигации или читаемости адресов. Она определяет объём пространства, которое поисковой системе потенциально приходится обнаруживать и обходить. Чем больше это пространство отличается от набора действительно нужных для поиска страниц, тем выше риск расходовать ресурс обхода на URL, которые не имеют самостоятельной ценности.

Откуда берётся лишнее пространство

Источников избыточного URL-пространства на практике немного, и они повторяются от сайта к сайту. Самый очевидный источник — параметры фильтрации и сортировки. Когда пользователь одновременно применяет несколько фильтров, количество комбинаций быстро растёт. Уже три-четыре параметра с несколькими значениями каждый могут создавать тысячи технически уникальных URL, содержимое которых при этом отличается лишь незначительно.

Параметры сессии и отслеживания тоже исторически были источником большого количества дублей. Речь идёт, например, о метках аналитических систем и идентификаторах сессии. Сегодня эта проблема встречается реже: современные CMS и системы аналитики обычно не требуют добавлять такие параметры к каждому основному URL. Однако полностью исключать их влияние на структуру сайта нельзя.

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

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

Что случилось с готовыми инструментами для решения этой задачи

Здесь стоит сделать историческую оговорку, потому что часть рекомендаций, которые до сих пор встречаются в материалах по SEO, уже устарела.

Долгое время в Google Search Console существовал специальный инструмент для работы с параметрами URL. Он появился ещё в 2009 году в Google Webmaster Tools и позволял указать, как поисковой системе следует обращаться с конкретным параметром: учитывать ли его при определении содержимого страницы или считать его несущественным. В марте 2022 года Google объявил о закрытии этого инструмента. Компания объяснила решение тем, что, по её оценке, лишь около 1% настроек действительно помогали управлять обходом. 26 апреля 2022 года инструмент окончательно прекратил работу.

После этого Google сделал ставку на автоматическое определение назначения параметров. Для случаев, когда владельцу сайта необходимо явно ограничить обход, компания по-прежнему указывает на robots. txt как один из доступных механизмов. При этом robots. txt управляет именно обходом URL, а не их индексацией, поэтому использовать его как универсальную замену прежнему инструменту нельзя.

С пагинацией произошла похожая история. Раньше на страницах последовательности рекомендовали использовать атрибуты rel=«next» и rel=«prev», чтобы сообщить поисковой системе о связи между отдельными страницами списка. В марте 2019 года Google сообщил, что больше не использует эти атрибуты как сигнал для индексации. Позднее представитель компании уточнил, что Google фактически перестал учитывать их значительно раньше. При этом сама пагинация никуда не исчезла: страницы последовательности по-прежнему могут быть обычными URL, которые поисковая система обнаруживает и обходит.

Из этой истории стоит вынести не ностальгию по исчезнувшим инструментам, а более практический вывод. Рекомендации, которые когда-то давали владельцу сайта дополнительный способ управлять конкретным механизмом обхода, со временем могут потерять актуальность. Поисковая система совершенствует собственные алгоритмы, а часть задач переносится с ручной настройки на автоматическую обработку.

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

Три инструмента и путаница вокруг них

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

Robots. txt

Robots. txt управляет самим обходом URL. Если путь запрещён правилами robots. txt, поисковый робот не должен обращаться к нему напрямую. Это позволяет не расходовать ресурс обхода, о котором шла речь в главе 6.

Но у такого решения есть важное ограничение. Если поисковый робот не может получить страницу, он не может прочитать её содержимое, включая директивы noindex или canonical, если они находятся в HTML. При этом сам URL всё равно может попасть в поисковую базу, например если на него ведут внешние ссылки. В таком случае Google может показывать адрес без содержимого страницы.

Поэтому robots. txt не стоит использовать как универсальный способ запретить индексацию. Если задача заключается именно в том, чтобы страница не попадала в индекс, блокировка обхода может помешать поисковой системе увидеть соответствующую директиву. Robots. txt прежде всего подходит для управления самим обходом, особенно когда запросы к определённым URL создают ненужную нагрузку на сервер.

Noindex

Noindex решает другую задачу. Эта директива сообщает поисковой системе, что страницу не следует включать в индекс. Она может находиться в HTML страницы или передаваться через HTTP-заголовок. Чтобы увидеть noindex, поисковый робот должен получить документ и обработать его.

Отсюда следует важное практическое правило: robots. txt и noindex нельзя рассматривать как два независимых запрета, которые нужно обязательно использовать одновременно. Если URL закрыт в robots. txt, Google может не получить страницу и, следовательно, не увидеть находящуюся в ней директиву noindex. В результате URL при определённых условиях всё равно может появиться в поиске.