Виявлення та блокування фейкових Googlebot за допомогою .htaccess — це процес відсіву шкідливих ботів, які маскуються під Googlebot, на основі User-Agent, перевірки IP та аналізу логів доступу, з метою зупинити їх із відповіддю 403, не заважаючи при цьому справжнім пошуковим роботам Google. Найнадійніший підхід — не покладатися лише на User-Agent, а використовувати офіційні IP-діапазони Google або зворотну DNS-перевірку, спочатку вести логування, а потім поступово впроваджувати правила в .htaccess.
Багато зловмисних ботів, аби обійти фаєрволи та прості фільтри, маскуються під Googlebot, Google-InspectionTool, AdsBot-Google або Googlebot-Image. Сайт-власники часто бояться блокувати Googlebot, тому це створює вразливість, що призводить до крадіжки контенту, перевантаження ресурсів, підробленого трафіку, спаму в формах, спроб злому та спотворення SEO-даних. Особливо це відчутно на спільних хостингах, сайтах на WordPress, WooCommerce, новинних порталах і блогах із частими оновленнями, де подібний трафік швидко виснажує CPU, оперативну пам’ять і дискові операції. У цій статті ми крок за кроком розглянемо, як розпізнати фейкові Googlebot, налаштувати безпечні правила .htaccess і не блокувати справжніх роботів. Якщо вам потрібна безпечна, швидка та масштабована інфраструктура для сайту, радимо також ознайомитися з Hostragons рішення для веб-хостингу та встановлення сертифіката SSL.
Що таке фейковий Googlebot і чому він небезпечний?
Фейковий Googlebot — це автоматичний бот, який у HTTP-запиті вказує User-Agent як Googlebot, але IP-адреса не належить Google. User-Agent — це простий текст, що ідентифікує клієнта, тому будь-хто може підробити його. Через це сам по собі User-Agent не є надійним підтвердженням.
Справжній Googlebot сканує сайт для індексації, виявлення оновлень і збору сигналів якості для пошукової видачі. Фейковий Googlebot часто має інші цілі: збирає ціни, копіює контент, досліджує панелі управління, навантажує пошукові сторінки, шукає вразливості плагінів. Деякі зловмисники надсилають десятки запитів на секунду, що може суттєво сповільнити навіть невеликий сайт.
Фейкові боти найчастіше виявляються за такими ознаками:
- Сотні запитів з помилками 404, 403 або 500 за короткий час.
- Сканування чутливих шляхів, таких як wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
- User-Agent схожий на Googlebot, але IP не належить до Google ASN чи офіційних діапазонів.
- Ігнорування правил robots.txt та відвідування сторінок фільтрів, кошика, акаунту.
- Ненормально висока частота запитів до одних і тих самих URL, що відрізняється від поведінки справжнього Googlebot.
Чому перевірка лише User-Agent недостатня?
Просто вказати в HTTP-заголовку, що ви Googlebot, не означає, що це справді так. Наприклад, проста команда curl може підробити User-Agent. Тому у .htaccess блокувати або пропускати всі запити з Googlebot — це помилка. Блокування може порушити справжнє сканування, а пропуск — залишить доступ зловмисникам.
Нова стратегія безпеки та SEO 2026 року складається з трьох рівнів: перевірка заявленої ідентичності, підтвердження IP або DNS, та моніторинг аномальної поведінки в логах. Такий підхід збереже видимість сайту в пошуку й убезпечить сервер від зайвого навантаження.
Як перевірити справжність Googlebot?
Google рекомендує два основні способи перевірки роботів: зворотне DNS і офіційні IP-діапазони. При зворотному DNS перевіряється, чи домен IP-адреси закінчується на googlebot.com або google.com, а потім цей домен має знову резолвитися до тієї ж IP. Така подвійна перевірка унеможливлює обман через підроблені PTR записи.
Другий спосіб — використовувати офіційні IP-адреси Google, опубліковані у JSON-форматі для Googlebot, спеціальних ботів та користувацьких тригерів. Оскільки ці списки можуть змінюватися, довіряти застарілим ручним спискам небезпечно. Якщо ви керуєте VPS чи сервером, рекомендується регулярно автоматично оновлювати ці списки у фаєрволі або Apache. Для спільного хостингу можна працювати з логами, .htaccess і модулями безпеки.
Логіка блокування фейкових Googlebot через .htaccess
.htaccess — це файл конфігурації для Apache, який дозволяє задавати правила на рівні каталогу: перенаправлення, обмеження доступу, стиснення, кешування та базові заходи безпеки. Для блокування фейкових Googlebot .htaccess аналізує запити за певними умовами і відхиляє їх із кодом 403 Forbidden.
Однак .htaccess не підходить для реального часу зворотної DNS-перевірки, бо HostnameLookups зазвичай вимкнені через навантаження. Тому найбільш ефективний спосіб у .htaccess — порівняння User-Agent Googlebot з allowlist офіційних IP або ж посилене фільтрування підозрілих шляхів. Для складнішої валідації застосовують WAF, фаєрволи, CDN або автоматизовані скрипти. Допоможе у плануванні й що таке CDN та його вплив на продуктивність сайту.
Покрокова інструкція: виявлення та блокування фейкових Googlebot
1. Аналізуйте логи доступу
Перед написанням правил проаналізуйте access log за 24-72 години. Якщо трафік великий, навіть година дасть достатньо даних. Звертайте увагу на IP, дату, URL, HTTP статус, розмір відповіді, реферер і User-Agent. Наприклад, якщо один IP робить 800 запитів за 10 хвилин, більшість із яких повертають 404, і маскується під Googlebot — це чіткий сигнал підозри.
У панелях cPanel чи подібних можна завантажити Raw Access Logs. Через SSH з grep, awk і sort можна фільтрувати IP за поведінкою, щоб оцінити активність ботів із User-Agent Googlebot не по одному запиту, а по IP в цілому.
2. Перевірте IP, що видають себе за Googlebot
Після виявлення підозрілих IP виконайте зворотне та пряме DNS-сканування. Якщо PTR запис IP виглядає як crawl-66-249-66-1.googlebot.com — це перший крок до підтвердження. Потім цей домен має резолвитися назад у ту ж IP. Якщо цього немає — IP не можна вважати справжнім Googlebot.
Ця перевірка критична для сайтів із високими SEO-вимогами, щоб уникнути випадкового блокування справжніх роботів, що може призвести до затримок індексації, зниження позицій та помилок у Google Search Console.
3. Спершу логування, потім блокування
Для безпечної роботи рекомендуємо не блокувати одразу, а спочатку вести спостереження. Записуйте підозрілі IP та User-Agent. Потім обмежуйте доступ лише до явно шкідливих шляхів. На завершальному етапі блокувати всі запити з Googlebot User-Agent, які не належать до офіційних IP-діапазонів Google.
Це особливо важливо для інтернет-магазинів, де помилки в правилах можуть зашкодити оплаті, кошику або оновленню товарів. Якщо у вас великий трафік — тестуйте правила на тестовому середовищі. Такі процеси, як Перенос сайту WordPress та створення тестового середовища, допоможуть мінімізувати ризики.
Приклади безпечних правил .htaccess
Перед безпосереднім впровадженням прикладів протестуйте їх відповідно до вашого середовища Apache, активних модулів і прав хостингу. Зазвичай підтримується Apache 2.4 і mod_rewrite, але деякі параметри в спільних хостингах можуть бути обмежені. Перед змінами обов’язково робіть резервну копію .htaccess — одна помилка може викликати 500 Internal Server Error.
Простий фільтр за поведінкою: блокування фейкових ботів на чутливих шляхах
Цей метод забороняє ботам, які видають себе за Googlebot, доступ до адміністративних і потенційно небезпечних файлів. Справжньому Googlebot не потрібно сканувати wp-login.php, phpmyadmin чи бекапи, тому ризик помилкового блокування мінімальний.
- RewriteEngine On
- RewriteCond %{HTTP_USER_AGENT} (Googlebot|Google-InspectionTool|AdsBot-Google|Mediapartners-Google) [NC]
- RewriteCond %{REQUEST_URI} (wp-login[.]php|xmlrpc[.]php|phpmyadmin|adminer|backup|[.]sql|[.]zip) [NC]
- RewriteRule ^ - [F,L]
Правило повертає 403, якщо клієнт із User-Agent Googlebot заходить на вказані чутливі шляхи. Це не впливає на SEO, бо Google зазвичай не індексує такі локації. Проте для WordPress рекомендується перевірити взаємодію з плагінами безпеки, XML-RPC та віддаленими сервісами.
Allowlist IP: порівняння заявленого Googlebot із офіційними діапазонами
Більш надійний підхід — пропускати запити з User-Agent Googlebot лише якщо IP належить офіційним діапазонам. Нижче наведено приклад логіки, IP-адреси слід оновлювати відповідно до актуального JSON списку Google.
- RewriteEngine On
- RewriteCond %{HTTP_USER_AGENT} (Googlebot|Googlebot-Image|Googlebot-News|Google-InspectionTool|AdsBot-Google) [NC]
- RewriteCond expr "! ( %{REMOTE_ADDR} -ipmatch '66.249.64.0/19' || %{REMOTE_ADDR} -ipmatch '64.233.160.0/19' || %{REMOTE_ADDR} -ipmatch '72.14.192.0/18' )"
- RewriteRule ^ - [F,L]
Ці IP-діапазони — приклад. Для продакшн-середовища використовуйте актуальні списки, автоматично оновлювані. Якщо ваш сервер не підтримує директиву -ipmatch або Apache 2.4, зверніться до хостинг-провайдера. Альтернативою є конфігурація на рівні CDN або WAF.
Обмеження швидкості підозрілих запитів
.htaccess не найкращий інструмент для складного rate limiting, але може допомогти припинити деякі шкідливі дії на ранньому етапі. Для повноцінного обмеження варто застосовувати mod_evasive, mod_security, функції CDN або захист на рівні додатку. Особливо небезпечні боти, що роблять понад 5-10 запитів на секунду, збільшують навантаження на базу даних. Фільтри, пошук і категорії в WordPress часто піддаються атакам. Тут допоможуть правила robots.txt, canonical, noindex і додаткові заходи безпеки. Детальніше про оптимізацію швидкості у Посібник з оптимізації швидкості WordPress.
Таблиця порівняння: коли який метод краще використовувати?
| Метод | Переваги | Недоліки | Рекомендоване застосування |
|---|---|---|---|
| Перевірка лише User-Agent | Дуже проста у налаштуванні | Легко підробляється, високий ризик помилок | Не використовується самостійно, лише як початковий фільтр |
| Зворотне DNS-підтвердження | Надійна перевірка справжності Googlebot | Не практично у .htaccess, потребує автоматизації | Застосовується в аналізі логів, WAF або серверних перевірках |
| Allowlist IP Google | Швидке та ефективне блокування | Потрібно регулярно оновлювати, інакше помилки | Ідеально для правил Apache, фаєрволів і CDN |
| Блокування за поведінкою | Захищає чутливі шляхи та типові атаки | Не підтверджує ідентичність | Ефективно для захисту wp-login, xmlrpc, резервних копій |
| Захист CDN/WAF | Обмеження швидкості, оцінка ботів, централізоване управління | Неправильне налаштування може вплинути на користувачів | Рекомендується для сайтів із великим трафіком і e-commerce |
Контрольний список, щоб не заблокувати справжній Googlebot

Головний ризик при блокуванні фейкових Googlebot — випадково заборонити справжніх. Після кожної зміни користуйтеся цим чеклистом:
- Перевірте у звітах Google Search Console, чи немає різких спадів або зростань 403 помилок.
- Перегляньте логи сервера на наявність запитів від офіційних Google IP із кодами 200, 301 або іншими коректними.
- Переконайтеся, що robots.txt не блокує доступ Googlebot до важливих розділів, крім тих, що свідомо закриті.
- Тестуйте сайт після змін: карта сайту, головна, категорії, ключові сторінки.
- Документуйте джерело і дату останнього оновлення IP-списків.
Для SEO 403 — це сильний сигнал. Якщо справжній Googlebot часто отримує 403, індексація може погіршитись. Тому 403 потрібно застосовувати тільки до небажаних ботів і критичних зон. У випадках технічного обслуговування чи перевантаження доцільні 429 Too Many Requests, але для простого блокування 403 більш зрозумілий і поширений.
Додаткові заходи для WordPress і інтернет-магазинів
На WordPress-сайтах фейковий Googlebot часто цілиться у xmlrpc.php, wp-login.php, REST API, сторінки пошуку та архіви авторів. В e-commerce атакують фільтри, запити на залишки товарів, кошик і варіації продуктів. Тому важливо не лише боротися з підробками Googlebot, а й підтримувати загальний захист від ботів.
- Впровадьте двофакторну аутентифікацію і обмеження спроб входу.
- Вимкніть або обмежте непотрібні XML-RPC функції.
- Використовуйте noindex, canonical і правила robots.txt для сторінок пошуку та фільтрів.
- Підтримуйте актуальні версії PHP, тем і плагінів.
- Активуйте SSL для безпечного HTTPS-з’єднання. Докладніше у Hostragons SSL сертифікати.
- Регулярно перевіряйте DNS-записи домену, уникайте помилок і слабких налаштувань. Детальніше Перевірка домену та управління DNS.
Як бот-трафік впливає на ресурси сервера?
Бот-трафік — це не лише питання безпеки, а й продуктивності хостингу. Запит на статичне зображення — це мало ресурсів, а пошуковий запит WordPress чи запит фільтра WooCommerce запускає складні запити до бази даних. Якщо фейковий Googlebot робить 300 динамічних запитів на хвилину, PHP-процеси можуть завантажитися, з’єднання з БД збільшаться, і реальні користувачі відчують затримки.
Для прикладу: якщо сторінка фільтра витрачає 250 мс на обробку, 600 бот-запитів за хвилину створять навантаження в 150 секунд процесора. Це призведе до зростання часу першого байта (TTFB), що негативно позначається на Core Web Vitals і досвіді користувачів, а відтак і на конверсії. Тому блокування ботів — це важлива частина не лише безпеки, а й SEO та оптимізації продуктивності.
Як перевірити, чи працюють ваші правила?
Після додавання правил у .htaccess зробіть три типи тестів. По-перше, відкрийте звичайним браузером головну і ключові сторінки сайту, а також сторінки входу. По-друге, перевірте URL у Google Search Console через інструмент перевірки URL. По-третє, проаналізуйте логи — чи отримують підозрілі IP з User-Agent Googlebot відповідь 403, а офіційні IP — ні.
Для тестів із командного рядка можна симулювати User-Agent Googlebot, але це не підтверджує справжність IP — лише показує, чи спрацьовує правило по User-Agent. Основна перевірка має бути через IP і DNS. Якщо після внесення правил бачите помилку 500, ймовірно, є синтаксична помилка у .htaccess. Відкотіть зміни, перевірте логи помилок і сумісність директив із сервером.
План регулярного оновлення правил
Блокування ботів — це постійна робота. IP-адреси Google можуть змінюватися, шаблони ботів змінюються, структура сайту оновлюється. Для сайтів із низьким трафіком достатньо перевіряти логи раз на місяць. Для новинних, торгових і великих сайтів — краще робити це щотижня. Для великих проєктів рекомендується впроваджувати автоматичні сповіщення: наприклад, якщо з IP, що імітують Googlebot, надходить занадто багато запитів без підтвердження, надходить повідомлення адміністратору.
Також важливо вести версіонування .htaccess, зберігати резервні копії з датою, наприклад htaccess-2026-02-15.bak — це пришвидшить відновлення у випадку проблем. Якщо у проєкті кілька адміністраторів, корисно документувати зміни і причини, щоб уникнути непорозумінь.
Висновок
Виявлення та блокування фейкових Googlebot за допомогою .htaccess, при правильному підході, збереже SEO-позиції сайту і захистить сервер від шкідливих ботів. Головне правило — не довіряти лише User-Agent, а комплексно перевіряти IP, DNS, поведінку і логи. Спочатку спостерігайте, потім обмежуйте доступ до ризикових зон, а наприкінці застосовуйте allowlist із актуальними IP Google.
Інфраструктура Hostragons пропонує безпечний хостинг, актуальні SSL-сертифікати, правильні DNS та регулярне резервне копіювання, що разом забезпечує стабільну роботу сайту. Ви можете почати з аналізу бот-трафіку на вашому сайті і за потреби перейти на більш потужний і захищений тариф у Hostragons пакети хостингу.
Поширені запитання
Чи впливають фейкові Googlebot на мої реальні позиції у пошуку?
Непрямо так. Фейкові бот-атаки виснажують серверні ресурси, через що справжні користувачі і Googlebot отримують повільні відповіді. Крім того, підроблені запити спотворюють логи і аналітику, що може збити SEO-стратегію. Правильне блокування допомагає зберегти бюджет сканування і продуктивність.
Чи варто блокувати всі Googlebot User-Agent через .htaccess?
Ні. Це призведе до блокування справжніх роботів і проблем з індексацією. Запити з Googlebot слід підтверджувати через IP або DNS, і блокувати лише підозрілі. Найкраще поєднувати allowlist IP із поведінковими правилами.
Як часто оновлювати список IP Googlebot?
Для сайтів із великим трафіком — щотижня, для менших — щомісяця. Оптимально використовувати офіційні JSON-джерела Google для автоматичного оновлення. Ручні та застарілі списки можуть призвести до помилкового блокування.
Після додавання правил у .htaccess отримую помилку 500, що робити?
Помилка 500 часто викликана синтаксичними помилками, невідповідними директивами або помилковим екрануванням символів. Відкотіть останні зміни, перевірте логи помилок і сумісність Apache 2.4 та mod_rewrite у вашому середовищі. Завжди робіть резервну копію .htaccess перед правками.
Якщо я використовую CDN або WAF, чи потрібні правила в .htaccess?
CDN та WAF — це потужний захист від ботів, але .htaccess все одно корисний як додатковий рівень безпеки на сервері. Найкращий результат дає комбінація обмежень на CDN/WAF та правил у .htaccess для захисту критичних зон сайту.