Хабравчане, приветсвую!
Так было решено волей судьбы, ну или просто мной) Я являюсь соучредителем одной SEO-студии и периодически люблю вместе с менеджерами разбирать наши проекты: что там происходит с сайтом, где проседаем, какие есть боли у клиента и что вообще с этим делать.
И сегодня как раз расскажу про один такой разбор. Ситуация сначала выглядела довольно обычно, но в процессе мы докопались до интересной штуки. Покажу, как разбирались, что нашли и к какому выводу пришли. А в конце (бонус) дам готовую рекомендацию сеошникам и владельцам коммерческих сайтов, которую можно забрать себе и проверить на своих проектах.
Название сайта здесь опущу, проект клиентский, а для самой истории домен вообще не важен.
В общем есть сайт, по SEO всё выглядело вполне прилично. Видимость росла, позиции были, органический трафик в Метрике тоже. В отчёте можно открыть график, показать динамику и сказать: работа идёт.
Проблема была в другом.
В какой-то момент клиент задал простой вопрос:
если на сайт действительно приходит столько людей, где заявки?
Вопрос неприятный именно своей простотой (кто работал с клиентами, тот поймет).
Можно открыть посадочные страницы. Посмотреть коммерческие и информационные запросы. Сегментировать географию. Проверить мобильный трафик. Объяснить, что человек, который читает статью, не обязан через три минуты покупать услугу.
Всё это справедливо.
Но чем дольше я смотрел на графики, тем сильнее меня цепляла другая мысль.
А сколько там вообще людей?
Сначала я полез в Метрику
Первой мыслью было проверить самое очевидное: роботный трафик.
И тут легко построить красивую, но неправильную теорию:
Googlebot ходит по сайту, Метрика считает его посетителем, поэтому посещаемость большая, а заявок нет.
С Googlebot всё несколько сложнее.
Яндекс Метрика умеет определять роботов. Тех, кто представился известным User-Agent, она исключает из обычной статистики сразу. Отдельно Метрика определяет автоматический трафик по поведенческим и техническим сигналам. Такие визиты по умолчанию могут присутствовать в статистике, но их можно посмотреть отдельно и сравнить отчёты с роботами и без них.
То есть перед тем как обвинять ботов, я бы для любого проекта сделал первое очень простое сравнение:
Период: одни и те же 30 дней Все визиты ↓ Визиты без роботов ↓ Органические визиты без роботов ↓ Целевые действия ↓ Реальные заявки в CRM
168 000 визитов → 144 480 визитов без роботов → 113 760 органических визитов без роботов → 1 286 целевых действий → 278 реальных заявок в CRM.
Если после исключения определённых Метрикой роботов 168 тысяч визитов превращаются в 144 тысячи — очевидно, объяснить ими отсутствие заявок полностью не получится.
Если превращаются в 105 тысяч — разговор уже интереснее.
Но даже после этого остаётся другой слой.
Метрика показывает то, что увидел установленный на странице счётчик.
Сервер видит вообще всех, кто до него дошёл.
Поэтому следующим файлом у меня стал access.log.
Оказалось, что машины уже давно составляют очень заметную часть веба
Прежде чем копаться в конкретных логах, мне стало интересно, какого вообще масштаба автоматический трафик сегодня.
По данным Thales 2026 Bad Bot Report, в 2025 году на ботов пришлось 53% интернет-трафика, причём 40% общего трафика компания классифицировала как bad bots. За тот же год её инфраструктура заблокировала 17,2 трлн bad-bot requests.
Здесь надо сделать оговорку.
Это не означает:
на вашем интернет-магазине ровно 53% посещений — роботы.
Это измерения конкретной инфраструктуры с конкретной методологией.
Но сам порядок величины хорошо объясняет, почему смотреть только на браузерную аналитику иногда мало.
AI тоже заметно поменял картину. Cloudflare пишет, что в июне 2026 года 52% идентифицированных crawler requests в их наблюдаемой экосистеме относились к AI training, ещё более 36% приходились на mixed-use crawlers, которые совмещают поиск, агентские сценарии и обучение.
Интернет всё меньше похож на модель:
человек → сайт Google → сайт
Скорее уже так:
И это ещё упрощённая схема.
Что вообще находится в access.log
Типичная строка nginx выглядит примерно так:
66.249.xxx.xxx - - [12/Aug/2026:11:42:16 +0300] "GET /catalog/example/ HTTP/2.0" 200 18432 "-" "Mozilla/5.0 (...) Googlebot/2.1 ..."
Из неё можно получить:
IP;
дату и время;
HTTP-метод;
URL;
HTTP status;
объём ответа;
Referer;
User-Agent.
Но здесь находится первая ловушка.
Допустим, сервер получил:
9 842 317 HTTP requests
а Метрика показывает:
168 000 визитов
Из этого совершенно не следует, что остальные 9 674 317 запросов сделали роботы.
Один обычный человек открывает HTML, после чего браузер может запросить:
/index.html /styles.css /app.js /logo.svg /font.woff2 /photo-1.webp /photo-2.webp /api/menu
Один просмотр страницы легко превращается в десятки HTTP-запросов.
А какой-нибудь простой crawler, наоборот, может забрать один HTML и уйти.
Поэтому:
HTTP request ≠ pageview ≠ visit ≠ человек.
Это первая вещь, которую я бы зафиксировал любому SEO-шнику перед анализом логов.
Конечно, сначала я сделал grep
Самый быстрый способ выглядит примерно так:
grep -Ei "bot|crawler|spider" access.log | wc -l
Получается число.
Причём обычно довольно убедительное.
Проблема только в том, что мы посчитали строки, содержащие bot, crawler или spider.
А хотелось узнать количество запросов автоматических клиентов.
Это разные задачи.
Есть:
роботы с честным User-Agent;
поисковые crawler;
SEO-парсеры;
AI-crawlers;
мониторинги;
headless-браузеры;
автоматизация с User-Agent Chrome;
настоящие браузеры;
клиенты, которые вообще представились кем захотели.
На этом этапе у меня уже могла получиться красивая цифра для заголовка.
К счастью, я решил её проверить.
Если написано Googlebot, это ещё не Google
В логах довольно быстро находятся такие строки:
Mozilla/5.0 ... Googlebot/2.1 ...
Кажется, вопрос закрыт.
Но User-Agent — это обычная строка, которую отправляет клиент.
Я могу прямо сейчас написать собственный скрипт:
User-Agent: Googlebot
и внезапно стать Google. По крайней мере для простого анализатора логов.
Самое забавное, что Google объяснял эту проблему ещё 20 сентября 2006 года.
В официальном блоге тогда прямо писали: любой спамер может назвать своего робота Googlebot. Для проверки Google предложил делать reverse DNS lookup, проверять hostname, после чего выполнять forward lookup и убеждаться, что он возвращает исходный IP.
В 2026 году схема по сути та же.
Google сейчас предлагает два способа:
reverse DNS → hostname Google → forward DNS → исходный IP;
либо проверка IP по официально публикуемым диапазонам crawler.
То есть:
IP из access.log ↓ reverse DNS ↓ crawl-...googlebot.com ↓ forward DNS ↓ получили исходный IP? / \ да нет ↓ ↓ Googlebot что-то другое
Именно тут мне особенно понравилось, насколько хорошо эта история продолжает предыдущую с DNS.
Мы опять начали с SEO, а закончили командой host.
С Яндексом идея похожая: поисковик также рекомендует проверять робота через DNS, а не только верить заявленному User-Agent.
Дальше начался настоящий зоопарк
Поисковые системы хотя бы понятны.
Но рядом с ними всё чаще встречается совершенно другая группа.
Например, OpenAI сейчас разделяет несколько разных механизмов доступа к сайтам.
OAI-SearchBot используется для поисковых функций ChatGPT.
GPTBot может обходить контент, который используется для улучшения и обучения generative AI foundation models.
ChatGPT-User связан с отдельными действиями пользователя и автоматическим crawler в обычном смысле не является. Для первых двух OpenAI отдельно поддерживает управление через robots.txt.
Это важная разница.
Строка:
ChatGPT сделал 15 000 запросов к сайту
почти ничего не говорит.
Нужно знать, кто именно сделал эти запросы.
То же касается других AI-сервисов.
Но потом рядом появляются старые знакомые SEO-шника:
AhrefsBot SemrushBot MJ12bot DataForSeoBot
И здесь уже возник другой вопрос.
А зачем вообще я разрешаю им обходить коммерческий проект?
Есть поисковый робот, а есть тот, кто собирает данные для SEO-базы
Допустим, Googlebot обходит мои страницы.
Логика понятна: я хочу присутствовать в Google.
YandexBot — аналогично.
А что делает DataForSeoBot?
DataForSEO прямо пишет, что робот постоянно обходит веб, добавляет найденные ссылки в их backlink database и перепроверяет уже обнаруженные ссылки. Компания также документирует возможность полностью запретить ему обход через robots.txt.
У Majestic MJ12Bot отвечает за обнаружение данных для backlink index.
Semrush документирует несколько отдельных роботов. Основной SemrushBot используется для webgraph ссылок, SiteAuditBot — для Site Audit, есть отдельные SemrushBot-BA, SemrushBot-SI и другие. И для каждого опубликованы правила отключения через robots.txt.
Ahrefs тоже разделяет основной AhrefsBot и AhrefsSiteAudit; оба понимают robots.txt, а частоту обхода можно регулировать через Crawl-delay.
Получается полезное разделение:
ПОИСК / DISCOVERY Googlebot YandexBot Bingbot OAI-SearchBot ↓ обычно оставляем ВНЕШНИЕ SEO-БАЗЫ AhrefsBot SemrushBot MJ12bot DataForSeoBot ↓ решаем, нужны ли они нам вообще СВОЙ АУДИТ AhrefsSiteAudit SiteAuditBot Screaming Frog Sitebulb ↓ оставляем себе возможность сканировать
Я бы не называл это «защитой от конкурентов».
Это слишком громко.
Публичный сайт всё равно остаётся публичным. Конкурент может открыть браузер, написать свой crawler, взять данные из поисковой выдачи или использовать другую инфраструктуру.
Но бесплатно помогать нескольким крупным SEO-базам постоянно освежать данные своего проекта тоже необязательно.
А что со Screaming Frog?
Вот здесь вообще интересно.
Screaming Frog — не интернет-wide индекс вроде Ahrefs.
Это инструмент, который запускает конкретный пользователь.
По умолчанию SEO Spider соблюдает robots.txt, а его User-Agent — Screaming Frog SEO Spider. Сами разработчики даже публикуют готовое правило блокировки:
User-agent: Screaming Frog SEO Spider Disallow: /
Но есть нюанс размером с лягушку.
В настройках Screaming Frog пользователь может выбрать Ignore robots.txt, использовать другой preset User-Agent или вообще установить собственный HTTP User-Agent и отдельный Robots User-Agent.
То есть блокировка:
User-agent: Screaming Frog SEO Spider Disallow: /
остановит обычный корректно настроенный crawl.
От человека, который специально решил просканировать ваш публичный сайт, это защитой не является.
И это, кстати, очень хороший пример того, что robots.txt вообще делает.
Это правила для тех, кто согласился их соблюдать.
Firewall он не заменяет.
С Sitebulb ситуация концептуально похожая: инструмент позволяет выбирать или задавать собственный User-Agent, а по умолчанию соблюдает robots directives. В собственной документации Sitebulb даже рекомендует использовать уникальный custom User-Agent, когда инструмент нужно отдельно allowlist на сервере.
Я посмотрел robots.txt Хабра. Там есть чему поучиться
На этом месте я решил посмотреть, что делает площадка, куда, возможно, потом понесу эту статью.
То есть Хабр.
И у Хабра robots.txt довольно показательный.
На момент написания статьи для Яндекса там отдельно закрыты:
/search/ /ru/search/ /en/search/ страницы fans страницы workers followers following
а UTM-параметры обрабатываются через Clean-param.
Для Googlebot отдельно закрыты поиск, социальные служебные страницы и URL с UTM-параметрами.
Для Slurp задан:
Crawl-delay: 8
а для остальных:
User-agent: * Crawl-delay: 10
плюс те же зоны поиска, UTM и страницы социальных связей пользователей.
То есть даже Хабр говорит роботам примерно следующее:
статьи читайте, а список из пяти тысяч подписчиков пользователя можно второй раз не обходить.
И неизвестным роботам ещё предлагает делать это без спешки.
Есть только важный технический нюанс.
Crawl-delay не входит в стандарт RFC 9309 и поддерживается не всеми crawler. Google прямо пишет, что Google Search эту директиву не поддерживает.
Так что копировать:
User-agent: * Crawl-delay: 10
на любой сайт и ждать, что Google начнёт ходить раз в десять секунд, не надо.
Но сама идея Хабра правильная: robots.txt можно использовать не только как кнопку “запретить весь сайт”, а для управления тем, куда роботам вообще есть смысл ходить.
Кстати, Clean-param, который Хабр использует для Яндекса, как раз предназначен для указания параметров URL, не меняющих содержимое страницы — например UTM. Яндекс официально документирует эту директиву.
А потом я посмотрел на Chrome, который вёл себя совсем не как Chrome
Самые понятные crawler закончились.
Остались строки вроде:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/... Safari/537.36
Вроде обычный браузер.
А потом этот браузер делает:
/page/1 /page/2 /page/3 /page/4 /page/5 /page/6 ...
несколько часов.
Без картинок.
Без CSS.
Почти без JavaScript.
С одинаковыми интервалами.
И ночью он почему-то тоже очень бодрый.
Один такой признак ничего не доказывает.
Корпоративный proxy может объединять много пользователей под одним IP. Headless Chrome умеет вести себя почти как обычный браузер. Браузеры могут работать с отключённым JavaScript. Мониторинги бывают очень похожи на человека.
Поэтому я отказался от прекрасного алгоритма:
if requests_per_minute > 100: bot = True
Жаль. Было бы удобно.
Практически полезнее разбить запросы хотя бы так:
verified search crawler known crawler known SEO bot known AI crawler suspected automation unclassified
Последняя категория нужна обязательно.
Иногда лучший результат анализа — честно сказать: я пока не знаю, кто это.
Хорошо, а как это повторить SEO-шнику без отдела Data Science
Вот здесь я бы уже перестал расследовать и оставил нормальный практический алгоритм.
Не нужен ELK-кластер, Hadoop и три DevOps.
Для начала достаточно Метрики, логов и пары часов.
Шаг 1. Берём одинаковый период
Например:
01.07.2026 — 31.07.2026
Из Метрики:
все визиты визиты без роботов органический трафик без роботов целевые действия
Из CRM:
реальные обращения
Из сервера:
access.log за те же даты
Обязательно проверить timezone.
Иначе можно полчаса искать аномалию, которую создали Москва и UTC.
Шаг 2. В логах сначала отделяем HTML от остального
Для SEO нас в первую очередь интересуют запросы страниц.
Иначе изображения, JS и CSS забьют статистику.
Условно отбрасываем:
.jpg .jpeg .png .webp .svg .css .js .woff .woff2 .ico
Остаются document requests, редиректы, ошибки и технические URL.
Шаг 3. Группируем по User-Agent
Получаем что-нибудь вроде:
Googlebot ... YandexBot ... bingbot ... GPTBot ... OAI-SearchBot ... AhrefsBot ... SemrushBot ... MJ12bot ... DataForSeoBot ... Screaming Frog SEO Spider ... Chrome / Safari / Firefox ... Other ...
Цифры сравниваем с общим количеством HTML/document requests, а не со всеми файлами подряд.
Шаг 4. Googlebot и YandexBot проверяем
Для самых активных IP:
host 66.249.66.1
потом:
host crawl-66-249-66-1.googlebot.com
Если вернулись к исходному IP — хорошо.
Для больших объёмов Google позволяет сверяться с официально публикуемыми IP ranges.
Шаг 5. Смотрим не только «сколько», но и «куда»
Вот это уже SEO.
Группируем URL:
коммерческие страницы категории карточки статьи пагинация фильтры UTM поиск 301 404 API служебные страницы
И смотрим распределение по crawler.
Если Google ходит в основном на нормальные страницы - хорошо.
Если сторонний crawler скачал 100 тысяч URL фильтров - вопрос уже другой.
Если половина запросов роботов приходит на 404, надо искать источник этих адресов.
Теперь решаем, кого реально хотим видеть
Для обычного коммерческого проекта я бы использовал примерно такую логику.
Оставить
Googlebot YandexBot Bingbot
Если нужен AI search — отдельно оставить соответствующий search crawler.
Например, OpenAI отдельно описывает OAI-SearchBot для появления сайта в ChatGPT Search и GPTBot, связанный с crawling для training use case. Поэтому один можно разрешить, а другой отдельно запретить через robots.txt. Эти настройки независимы.
То есть вполне осмысленная политика:
User-agent: OAI-SearchBot Allow: / User-agent: GPTBot Disallow: /
если именно этого хочет владелец проекта.
Подумать, нужны ли
AhrefsBot SemrushBot MJ12bot DataForSeoBot
Если мне от их обхода никакой пользы не нужно, я бы спокойно ограничил.
Базовый robots.txt для уменьшения внешнего SEO-crawling
Это не готовый robots.txt для любого сайта, а блок, который можно добавить к существующим правилам после проверки.
# Ahrefs — основной crawler внешней базы User-agent: AhrefsBot Disallow: / # Semrush — webgraph / backlink crawling User-agent: SemrushBot Disallow: / # Semrush Backlink Audit crawler User-agent: SemrushBot-BA Disallow: / # Semrush On Page / related tools User-agent: SemrushBot-SI Disallow: / # Majestic backlink crawler User-agent: MJ12bot Disallow: / # DataForSEO backlink crawler User-agent: DataForSeoBot Disallow: / # Обычный Screaming Frog crawl User-agent: Screaming Frog SEO Spider Disallow: /
Для Ahrefs, Semrush и DataForSEO такие механизмы управления официально документированы самими сервисами. Majestic также описывает MJ12Bot как crawler backlink index и заявляет поддержку правил robots.txt.
Со Screaming Frog повторюсь: это ограничит только crawler, который решил соблюдать ваши правила. Сам Screaming Frog позволяет пользователю игнорировать robots.txt, менять HTTP User-Agent и отдельно Robots User-Agent.
Поэтому robots.txt здесь уменьшает добровольный и стандартный crawl, а не строит противотанковый ров вокруг сайта.
А как тогда сканировать собственный сайт Screaming Frog?
Вот здесь можно сделать аккуратнее.
Screaming Frog позволяет задать собственный HTTP User-Agent и отдельно Robots User-Agent.
Частный вариант, берем за пример seo-gravity и используем для таких аудитов отдельный User-Agent:
SEOGravityAudit
И в robots.txt:
User-agent: SEOGravityAudit Allow: /
А стандартный:
User-agent: Screaming Frog SEO Spider Disallow: /
закрыть.
Это опять же не средство аутентификации: любой, кто узнает строку, может её повторить.
Если нужен реальный доступ только своему crawler, это уже делается не через robots.txt, а через сервер, firewall/CDN/WAF, IP allowlist или другой механизм контроля доступа.
Но для обычной SEO-гигиены схема удобная:
чужой стандартный Screaming Frog → robots.txt → stop наш Screaming Frog с нашим UA ↓ allow
У Sitebulb похожая идея: для allowlisting собственного аудита документация рекомендует custom User-Agent.
Я бы ещё забрал у Хабра несколько идей
Не буквально скопировал файл.
Именно идеи.
Внутренний поиск
Если сайт генерирует огромное количество страниц типа:
/search/?q=...
и они не нужны поиску:
Disallow: /search/
может быть вполне разумной мерой.
Сначала, конечно, нужно проверить, что мы случайно не закрываем ценные посадочные.
UTM
Хабр для Яндекса использует Clean-param, а для Google ограничивает UTM-варианты через Disallow.
Для Яндекса на обычном проекте можно рассмотреть:
User-agent: Yandex Clean-param: utm_source&utm_medium&utm_campaign&utm_term&utm_content /
если эти параметры действительно не меняют содержимое страницы. Назначение Clean-param именно такое.
Для Google я бы не копировал хабровский Disallow автоматически.
Сначала:
нормальные canonical;
отсутствие UTM во внутренних ссылках;
корректная генерация URL;
понятная структура сайта.
И уже потом решал, нужен ли дополнительный robots-control.
Социальные и технические бесконечности
У Хабра закрыты страницы вроде:
/users/.../followers/ /users/.../following/ /companies/.../fans/ /companies/.../workers/
Для коммерческого сайта эквивалентом могут быть:
бесконечные фильтры внутренний поиск сортировки служебные списки технические endpoints календарные страницы
То есть самая полезная идея здесь:
ограничивать не «ботов вообще», а бесполезное пространство URL.
Это сильно важнее списка из 80 User-Agent.
Нужно ли ставить Crawl-delay: 10 как у Хабра?
Только если понимаете, для кого.
У Хабра сейчас:
User-agent: Slurp Crawl-delay: 8
и:
User-agent: * Crawl-delay: 10
Но Crawl-delay не входит в стандарт Robots Exclusion Protocol, а Google Search его не поддерживает.
Поэтому я бы не добавлял его в стандартный robots.txt просто потому, что «Хабр же добавил».
Для Ahrefs и DataForSEO Crawl-delay, наоборот, официально поддерживается.
Если хочется не запрещать Ahrefs полностью, а просто уменьшить нагрузку:
User-agent: AhrefsBot Crawl-delay: 10
Можно сделать так.
То же с DataForSEO:
User-agent: DataForSeoBot Crawl-delay: 10
Но если задача именно не обновлять внешнюю SEO-базу своими данными, логичнее Disallow.
После изменений самое интересное — проверить, сработало ли
До изменения берём 30 дней:
AhrefsBot 32 640 requests SemrushBot 21 870 MJ12bot 16 490 DataForSeoBot 12 770
Добавляем правила.
Следующий сопоставимый период:
ДО ПОСЛЕ AhrefsBot 32 640 194 SemrushBot 21 870 316 MJ12bot 16 490 142 DataForSeoBot 12 770 97
И я бы сравнивал пять показателей:
1. Requests 2. Unique URLs 3. Переданные GB 4. 404 requests 5. Доля от HTML-запросов
Например:
AhrefsBot requests 32 640 → 194 unique URLs 12 488 → 3 404 1 126 → 0 traffic 2.8GB → 9MB
Это уже не теоретическая SEO-настройка.
Это измеримый результат.
Если официальный crawler после Disallow продолжает ходить, сначала проверяем простые вещи:
/robots.txt существует? ↓ возвращает HTTP 200? ↓ правильно написан User-Agent? ↓ правило находится на правильном host? ↓ бот успел перечитать robots.txt? ↓ это вообще настоящий бот этого сервиса?
Semrush, например, предупреждает, что после изменения robots.txt его crawler может сделать до 100 запросов или потратить до часа, прежде чем увидит изменения.
DataForSEO публикует reverse-DNS mask своего crawler и диапазоны адресов, так что его тоже можно проверять отдельно.
А если робот просто не слушается?
Тогда заканчивается SEO и начинается контроль доступа.
robots.txt говорит:
пожалуйста, не ходи сюда.
nginx/WAF говорит:
ты сюда не попадёшь.
Если неизвестный crawler делает:
/page/1 /page/2 /page/3 /page/4 ...
и игнорирует robots.txt, SEO-шнику достаточно собрать:
IP User-Agent частоту запросов URL время количество requests
и передать разработчику или администратору.
Дальше уже используются:
rate limiting;
IP/network block;
WAF rules;
CDN bot management;
challenge;
allowlist.
Причём массово банить IP самостоятельно я бы не начинал.
Общие proxy, мобильные сети, облака и распределённые crawler быстро превращают простую идею «заблокируем IP» в отдельную статью.
И возвращаемся к главному вопросу: где заявки?
Вся эта история началась вообще не из-за robots.txt.
Клиент спросил:
«Если трафик есть, где заявки?»
После анализа я бы собирал финальную картину в три слоя.
1. Аналитика
Все визиты 168 000 Без роботов 144 480 Органика без роботов 113 760 Целевые действия 1 286
2. Сервер
HTML requests 486 920 Verified search bots 116 861 SEO crawlers 83 770 AI crawlers 20 451 Suspected automation 47 728 Unclassified 218 110
3. Бизнес
Заявки CRM 278 Продажи 64
И только после этого отвечал клиенту.
Потому что возможны три совершенно разных результата.
Первый:
роботов на сервере оказалось много, но Метрика почти всех их уже исключила. Отсутствие заявок ими не объясняется.
Тогда идём в интент, посадочные и качество органического трафика.
Второй:
часть автоматизации действительно попадала в аналитическую статистику, и после её исключения объём человеческого трафика стал заметно скромнее.
Тогда первоначальный вопрос клиента был абсолютно правильным.
Третий:
обе причины работают одновременно.
Что, подозреваю, встречается чаще всего.
Что я в итоге сделал бы на обычном SEO-проекте
Если свести всю статью к одному практическому набору, получилось бы так.
Раз в месяц:
Метрика с роботами / без роботов ↓ органика ↓ лиды
На сервере хранить access.log хотя бы 30–90 дней.
В логах смотреть:
Googlebot YandexBot Bingbot AI crawlers AhrefsBot SemrushBot MJ12bot DataForSeoBot 404 301 фильтры UTM поиск параметры
Поисковых роботов проверять по DNS/IP, если данные критичны.
Из robots.txt убрать бесполезные пространства URL.
Отдельно решить, нужны ли внешние SEO-crawlers.
Минимальный блок для проекта, где они не нужны:
User-agent: AhrefsBot Disallow: / User-agent: SemrushBot Disallow: / User-agent: SemrushBot-BA Disallow: / User-agent: SemrushBot-SI Disallow: / User-agent: MJ12bot Disallow: / User-agent: DataForSeoBot Disallow: / User-agent: Screaming Frog SEO Spider Disallow: /
А для своих crawler использовать отдельную понятную политику.
Например:
User-agent: SEOGravityAudit Allow: /
И уже этим User-Agent запускать свой аудит.
Ещё раз: это не защита секрета Coca-Cola.
User-Agent подделывается.
Для настоящего ограничения нужен уровень сервера.
Но для нормальной гигиены проекта этого уже хватает, чтобы перестать добровольно обслуживать заметную часть ненужного crawling.
Вместо вывода
Когда клиент сказал «трафик есть, а заявок нет», я воспринимал слово трафик довольно однозначно.
Есть число в Метрике.
Вот трафик.
После логов всё стало менее удобно.
Есть визиты.
Есть посетители.
Есть просмотры.
Есть HTTP requests.
Есть поисковые crawler.
Есть AI-crawlers.
Есть backlink bots.
Есть Screaming Frog, который честно называется Screaming Frog.
И есть Screaming Frog, который одним кликом может перестать называться Screaming Frog.
Есть Chrome, который три часа подряд читает /page/1, /page/2, /page/3.
Есть Googlebot, который действительно Googlebot.
И есть кто-то, кто просто написал это в User-Agent — проблема, про которую Google рассказывал ещё в 2006 году.
А ещё есть Хабр, который сам довольно прагматично закрыл от crawler поиск, UTM-варианты и социальные служебные страницы, а части роботов вообще предложил немного сбавить скорость.
Так что кое-чему по robots.txt здесь действительно можно поучиться у площадки, на которой мы сейчас обсуждаем почему robots.txt) ну да ладно.
Только копировать его целиком всё-таки не стоит.
У Хабра свой "зоопарк".
У нас свой.
Главное после этой истории я бы сформулировал совсем коротко:
Метрика показывает, кто дошёл до аналитики. Логи показывают, кто дошёл до сервера. CRM показывает, ради кого всё это вообще было.
А robots.txt отвечает только на один вопрос - кого мы попросили вести себя прилично.
