Техническое SEO без мифов
Crawl-delay в robots.txt часто добавляют, чтобы снизить нагрузку от поисковых роботов. Но в 2026 году эта директива уже не является универсальным решением: Google её не поддерживает, Яндекс отказался от её учёта, а часть других роботов может трактовать её по-своему.
Ниже - практичная инструкция: когда crawl-delay вообще имеет смысл, чем его заменить, как не замедлить индексацию и что проверить перед правками в robots.txt.
Не ставить “на всякий случай”
Не работает
Использовать Вебмастер
Что такое crawl-delay простыми словами
Crawl-delay - это неофициальная директива robots.txt, которая просит робота делать паузу между запросами к сайту. Например, значение Crawl-delay: 5 означает просьбу не обращаться к сайту чаще одного раза в 5 секунд.
Проблема в слове “просит”. Это не жёсткий технический запрет, не стандарт для всех поисковых систем и не гарантия, что бот будет вести себя именно так.
Важно
Если сайт медленно отвечает, падает под ботами или получает тысячи технических URL в обходе, начинать нужно не с crawl-delay, а с логов сервера, дублей, параметров URL, кеширования и правил индексации.
Как Google, Яндекс и Bing относятся к crawl-delay
Самая частая ошибка - написать универсальный совет “добавьте crawl-delay для всех поисковиков”. На практике поисковые системы относятся к этой директиве по-разному.
| Система / робот | Учитывает crawl-delay? | Что делать вместо слепой настройки |
|---|---|---|
| Googlebot | Нет. Google поддерживает user-agent, allow, disallow и sitemap, но не crawl-delay. | Убирать дубли, ускорять сервер, исправлять 5xx, настраивать canonical, noindex и внутреннюю структуру. |
| Яндекс | Нет в старом смысле. Яндекс отказался от учёта crawl-delay и перенёс управление в инструмент “Скорость обхода”. | Использовать Яндекс.Вебмастер и чаще оставлять режим “Доверять Яндексу”, если нет доказанной нагрузки. |
| Bing / MSNBot | Да, но с ограничениями и риском замедлить обновление индекса. | Ставить только при подтверждённой нагрузке и выбирать минимальное значение. |
| SEO-краулеры и сторонние боты | Зависит от конкретного бота. | Для агрессивных роботов чаще эффективнее Disallow, firewall, rate limiting, Cloudflare/CDN или правила на сервере. |
Когда crawl-delay не решит проблему
Crawl-delay часто используют как “пластырь”, когда сайт уже технически болеет. Но если причина нагрузки в дублях, параметрах фильтров или слабом сервере, задержка не исправит источник проблемы.
Фасетные фильтры
Каталог генерирует тысячи URL с параметрами сортировки, цвета, размера, цены. Робот тратит обход на дубли вместо важных страниц.
Слабое кеширование
Каждый визит бота запускает тяжёлые PHP/SQL-запросы. Даже нормальная частота обхода может давать перегрузку.
Ошибки 5xx
Если сервер периодически отвечает 500, 502, 503 или 504, поисковики могут снизить доверие к стабильности сайта.
Лишние технические страницы
Корзина, поиск по сайту, личный кабинет, UTM-дубли, страницы пагинации и внутренние результаты поиска могут съедать crawl budget.
Если параллельно разбираете индексацию и запреты, полезно свериться с материалом про Meta robots, X-Robots-Tag и robots.txt: там проще понять, чем отличается запрет сканирования от запрета индексации.
Как проверить, нужен ли вам crawl-delay
Решение должно опираться не на чужой robots.txt, а на данные вашего сайта. Минимальный порядок проверки такой:
Собрать логи сервера
Отделить поисковых ботов от мусорных
Найти тяжёлые и лишние URL
Выбрать настройку: Вебмастер, robots.txt или сервер
Чек-лист проверки
- Посмотрите access logs за 7-14 дней: какие user-agent создают больше всего запросов.
- Проверьте, совпадают ли IP и reverse DNS с реальными ботами Google, Яндекса, Bing.
- Выделите URL, которые чаще всего обходятся: фильтры, сортировки, поиск, пагинация, параметры.
- Сравните пики обхода с ошибками 5xx, ростом TTFB, падениями сервера и жалобами пользователей.
- Проверьте robots.txt валидатором и убедитесь, что важные CSS, JS и коммерческие страницы не закрыты.
Пример плохого и хорошего подхода
Плохой вариант
Поставить большое значение “на всякий случай”, потому что так увидели у конкурента.
User-agent: *
Crawl-delay: 20
Disallow: /Риск: сайт может стать хуже доступен для обхода, а запрет Disallow: / вообще закрывает весь сайт от сканирования.
Хороший вариант
Сначала закрыть мусорные зоны, настроить карты сайта, убрать дубли и только потом ограничивать конкретного бота, если это подтверждено логами.
User-agent: *
Disallow: /wp-admin/
Disallow: /?s=
Disallow: /*?orderby=
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.ru/sitemap_index.xmlДля Яндекса скорость лучше смотреть в Яндекс.Вебмастере, а для мусорных и агрессивных ботов - использовать серверные ограничения.
Что спросить у SEO-специалиста или разработчика
Если подрядчик предлагает поставить crawl-delay, нормальный следующий вопрос - “на основании каких данных?”. Ответ должен быть не общим, а привязанным к логам, ботам, ошибкам и URL.
Какие роботы создают нагрузку и сколько запросов они делают в пиковые часы?
Какие важные страницы могут начать переобходиться медленнее после ограничения?
Почему не подходит кеширование, CDN, rate limiting, canonical, noindex или чистка параметров?
Какие метрики проверяем через неделю: ошибки, TTFB, количество просканированных URL, попадание в индекс?
Красные флаги в настройке robots.txt
- Подрядчик копирует robots.txt конкурента без анализа структуры вашего сайта.
- Crawl-delay ставят большим значением без логов и без понимания, какой бот грузит сервер.
- Закрывают CSS, JS, изображения или коммерческие разделы, а потом удивляются проблемам с индексацией.
- Путают “запретить сканирование” и “запретить индексацию”. Robots.txt не всегда удаляет URL из выдачи.
- Не проверяют результат после публикации: валидатор, Search Console, Яндекс.Вебмастер, логи, ошибки сервера.
Если задача шире, чем один robots.txt, посмотрите материал про GEO-продвижение сайта: там логика похожая - поисковикам и AI-системам нужно давать чистую, понятную и проверяемую структуру данных.
Честный блок: проблема может быть не в ботах
Иногда владелец сайта видит просадку, медленную индексацию или слабые заявки и думает, что виноваты роботы. На практике причина может быть в другом: слабый сервер, тяжёлая CMS, плохой оффер, низкая конверсия, сезонность, цена, некачественная обработка заявок или отсутствие аналитики.
Поэтому технические правки нужно связывать с бизнес-метриками. Если поисковый трафик есть, но заявок мало, один crawl-delay не поможет. Нужны аудит посадочных страниц, коммерческих факторов, скорости, форм, доверия и аналитики.
Что должно быть в норме
- Важные страницы доступны к сканированию и есть в sitemap.
- Сервер стабильно отвечает без массовых 5xx и резкого роста TTFB.
- Дубли и технические URL не съедают бюджет обхода.
- Заявки, звонки и формы отслеживаются в аналитике.
Для системной работы можно начать с SEO-продвижения с прозрачным планом работ, где технические задачи оцениваются вместе с трафиком, заявками и коммерческими факторами.
Что делать дальше: безопасный порядок действий
- Снимите факты. Логи, ошибки, частота обхода, user-agent, проблемные URL, нагрузка на сервер.
- Уберите технический мусор. Закройте лишние параметры, поиск по сайту, сортировки, служебные директории.
- Проверьте индексацию. Важные страницы должны быть доступны, внутренне связаны и указаны в sitemap.
- Настройте скорость там, где это реально работает. Для Яндекса - через Вебмастер, для Bing - осторожно и минимально, для агрессивных ботов - через сервер.
- Проверьте результат. Через 7-14 дней сравните логи, ошибки, скорость ответа, страницы в обходе и динамику индексации.
Не уверены, что robots.txt не мешает SEO?
Начните не с случайных правок, а с проверки: какие страницы открыты, какие закрыты, что видят Google и Яндекс, где теряется бюджет обхода и есть ли технические ошибки, влияющие на заявки.
