Source
Sneex SEO 🇺🇦 | User-Agent Googlebot більше не доводить нічогоGary Illyes із Google в ...
616 Views/Reach
2026-10-29 07:44
Message №1232
User-Agent Googlebot більше не доводить нічого
Gary Illyes із Google в інтерв’ю для Odys Podcast детально розібрав, як сьогодні працює ідентифікація ботів і чому поява AI-кроулерів зробила старі методи значно менш надійними. Головна теза проста: якщо в логах ви бачите Googlebot, це ще не означає, що до сайту прийшов Google.
Підмінити Googlebot дуже легко
User-Agent — це звичайний HTTP-заголовок, який crawler передає серверу. Будь-який бот може написати там Googlebot; за словами Illyes, технічно це буквально один рядок коду.
Тому Google рекомендує перевіряти crawler через офіційні IP-діапазони або reverse DNS. Illyes навіть використовує honeypot-сайти — спеціальні сторінки, які допомагають ловити crawler'ів, що називають себе Googlebot, але поводяться не так, як справжній бот Google.
Фейковий crawler при цьому може робити те, чого Googlebot не робить: агресивно завантажувати сторінки, збирати контент для інших цілей або створювати настільки багато запитів, що сайт починає витрачати зайвий bandwidth або взагалі падає.
AI зробив проблему масштабнішою
Illyes пов’язує частину росту такого crawling із попитом AI-компаній на training tokens. Інтернет фактично став величезним джерелом даних, які crawler'и намагаються «зібрати».
При цьому він зазначає, що поганий crawling не завжди означає зловмисну поведінку. Часто crawler просто неправильно реалізований: не має нормального rate limiting, не враховує навантаження на сервер або некоректно працює з правилами сайту.
robots.txt тут не є механізмом захисту. Це інструкція для ботів, яку crawler має добровільно виконувати. Якщо потрібно реально зупинити бота, блокування має відбуватися через CDN, WAF або на мережевому рівні.
Є й легітимні випадки, коли crawler може не слідувати robots.txt. Наприклад, user-triggered fetcher виконує конкретний запит користувача, тому логіка його роботи відрізняється від класичного пошукового crawler.
Google рухається до криптографічної перевірки
Окремо Illyes розповів про Web Bot Auth та HTTP Message Signatures. Ідея в тому, щоб бот криптографічно підписував HTTP-запит, а сервер міг перевірити, хто його реально відправив.
Це потенційно надійніше за IP і reverse DNS: IPv4-адрес мало, інфраструктура crawler'ів постійно змінюється, а новим сервісам складно підтримувати окремі IP-діапазони.
Google вже експериментує з підписаними запитами для AI-агентів. Паралельно існує Google-Extended — окремий токен у robots.txt, який дозволяє обмежити використання контенту для Gemini та інших AI-сценаріїв Google, не блокуючи звичайний Google Search.
Illyes також запропонував ідею reputation system для ботів, але визнав проблему: якщо рейтинг контролюватиме одна компанія, він неминуче буде упередженим. Тому майбутнє web crawling, схоже, рухається не до повного блокування анонімних ботів, а до можливості перевірити, хто саме робить запит і з якою ідентичністю.
Джерело: Odys Podcast — Gary Illyes про Googlebot, AI crawlers та Web Bot Auth
Gary Illyes із Google в інтерв’ю для Odys Podcast детально розібрав, як сьогодні працює ідентифікація ботів і чому поява AI-кроулерів зробила старі методи значно менш надійними. Головна теза проста: якщо в логах ви бачите Googlebot, це ще не означає, що до сайту прийшов Google.
Підмінити Googlebot дуже легко
User-Agent — це звичайний HTTP-заголовок, який crawler передає серверу. Будь-який бот може написати там Googlebot; за словами Illyes, технічно це буквально один рядок коду.
Тому Google рекомендує перевіряти crawler через офіційні IP-діапазони або reverse DNS. Illyes навіть використовує honeypot-сайти — спеціальні сторінки, які допомагають ловити crawler'ів, що називають себе Googlebot, але поводяться не так, як справжній бот Google.
Фейковий crawler при цьому може робити те, чого Googlebot не робить: агресивно завантажувати сторінки, збирати контент для інших цілей або створювати настільки багато запитів, що сайт починає витрачати зайвий bandwidth або взагалі падає.
AI зробив проблему масштабнішою
Illyes пов’язує частину росту такого crawling із попитом AI-компаній на training tokens. Інтернет фактично став величезним джерелом даних, які crawler'и намагаються «зібрати».
При цьому він зазначає, що поганий crawling не завжди означає зловмисну поведінку. Часто crawler просто неправильно реалізований: не має нормального rate limiting, не враховує навантаження на сервер або некоректно працює з правилами сайту.
robots.txt тут не є механізмом захисту. Це інструкція для ботів, яку crawler має добровільно виконувати. Якщо потрібно реально зупинити бота, блокування має відбуватися через CDN, WAF або на мережевому рівні.
Є й легітимні випадки, коли crawler може не слідувати robots.txt. Наприклад, user-triggered fetcher виконує конкретний запит користувача, тому логіка його роботи відрізняється від класичного пошукового crawler.
Google рухається до криптографічної перевірки
Окремо Illyes розповів про Web Bot Auth та HTTP Message Signatures. Ідея в тому, щоб бот криптографічно підписував HTTP-запит, а сервер міг перевірити, хто його реально відправив.
Це потенційно надійніше за IP і reverse DNS: IPv4-адрес мало, інфраструктура crawler'ів постійно змінюється, а новим сервісам складно підтримувати окремі IP-діапазони.
Google вже експериментує з підписаними запитами для AI-агентів. Паралельно існує Google-Extended — окремий токен у robots.txt, який дозволяє обмежити використання контенту для Gemini та інших AI-сценаріїв Google, не блокуючи звичайний Google Search.
Illyes також запропонував ідею reputation system для ботів, але визнав проблему: якщо рейтинг контролюватиме одна компанія, він неминуче буде упередженим. Тому майбутнє web crawling, схоже, рухається не до повного блокування анонімних ботів, а до можливості перевірити, хто саме робить запит і з якою ідентичністю.
Джерело: Odys Podcast — Gary Illyes про Googlebot, AI crawlers та Web Bot Auth