Як засекчы і заблакіраваць фальшывыя Googlebot з дапамогай .htaccess: бяспека і SEO для сайтаў

Засекчы і заблакіраваць фальшывыя Googlebot праз .htaccess — гэта працэс, калі вы адрозніваеце шкодныя боты, што выдаюць сябе за Googlebot, па User-Agent, IP-верыфікацыі і логах доступу, і спыняеце іх 403-ым адказам, не ўплываючы на сапраўдных Googlebot. Найбольш бяспечны метад: не давяраць толькі User-Agent, выкарыстоўваць афіцыйныя IP-спісы Google ці зваротную DNS-верыфікацыю, спачатку назіраць у логах, потым пісаць правілы .htaccess з асцярожнасцю.

Шматлікія шкодныя боты для абходу стандартных фаерволаў і фільтраў выдаюць сябе за Googlebot, Google-InspectionTool, AdsBot-Google або Googlebot-Image. Уладальнікі сайтаў часта баяцца перашкодзіць Google, і гэта стварае шчыліну для скрапінгу кантэнту, празмернага выкарыстання рэсурсаў, фальшывага трафіку, спаму ў формах, спробы ўваходу і псуты SEO-дадзеных. Асабліва гэта актуальна для shared-hosting, WordPress, WooCommerce, навінавых рэсурсаў і блогаў з частымі абнаўленнямі, дзе шкодныя боты хутка могуць дасягнуць межаў CPU, RAM і I/O. У гэтым гайдзе мы разглядзім, як распазнаць паводзіны фальшывых Googlebot, напісаць бяспечныя .htaccess-правілы і правесці неабходныя праверкі, каб не заблакіраваць сапраўдных ботаў. Для надзейнай, хуткай і маштабаванай інфраструктуры вашага сайта таксама можаце дадаць у план Hostragons рашэнні для веб-хостынгу і Устаноўка сертыфіката SSL.

Што такое фальшывы Googlebot і чым ён небяспечны?

Фальшывы Googlebot — гэта аўтаматызаваны бот, які ў HTTP-запыце паказвае User-Agent як Googlebot, але прыходзіць з IP, не звязаных з Google. User-Agent — просты тэкставы радок, які можна лёгка падрабіць. Таму адна толькі праверка User-Agent не гарантуе бяспеку.

Сапраўдны Googlebot скануе ваш сайт для індэксацыі, абнаўлення старонак і збору сігналаў якасці для пошукавых вынікаў. Фальшывыя Googlebot найчасцей маюць іншыя мэты: напрыклад, здымаюць цэны, крадуць кантэнт, правяраюць URL адміністрацыі, нагружаюць пошукавыя старонкі ці скануюць уразлівасці. Некаторыя атакуючыя боты робяць дзясяткі запытаў у секунду, што нават на невялікіх сайтах выклікае падзенне прадукцыйнасці.

На практыцы фальшывыя боты часта выяўляюцца па такіх сігналах:

• Сотні адказаў 404, 403 або 500 за кароткі час.
• Сканаванне важных шляхоў: wp-login.php, xmlrpc.php, admin, phpmyadmin, backup.zip.
• User-Agent выглядае як Googlebot, але IP не належыць Google ASN або афіцыйным IP-спісам.
• Ігнараванне robots.txt: боты ходзяць па фільтрах, пошуку, кошыку ці асабістых старонках.
• Запыты ад аднаго IP з вельмі высокай частатой, не характэрнай для сапраўднага Googlebot.

Чаму кантроль толькі User-Agent недастатковы?

Факт, што бот піша “Googlebot” у HTTP-загалоўку, не азначае, што ён ад Google. Напрыклад, праз curl у камандным радку User-Agent лёгка падрабіць. Таму .htaccess-правілы, што проста ловяць “Googlebot” і ўсе блакіруюць або дазваляюць, — памылка. Першае можа заблакіраваць сапраўдны Googlebot, другое — пакінуць сайт безабаронным перад шкоднымі ботамі.

Сучасная SEO і бяспека патрабуюць трохступенчатай стратэгіі: праверка заявленай асобы, верыфікацыя IP або DNS, аналіз паводзін у логах. Такі падыход захоўвае бачнасць сайта для Google і абараняе серверныя рэсурсы ад лішніх ботаў.

Як праверыць сапраўднага Googlebot?

Google рэкамендуе два спосабы праверкі: зваротная DNS і афіцыйныя IP-спісы. Пры зваротнай DNS IP павінен мець дамен googlebot.com або google.com, і гэты дамен пры зваротным рашэнні павінен вяртаць той жа IP. Гэта двухбаковая верыфікацыя, што прадухіляе падман з фальшывымі PTR-запісамі.

Другі спосаб — афіцыйныя спісы IP Google. Для Googlebot, спецыяльных сканераў і карыстальніцкіх fetchers публікуюцца асобныя JSON-спісы. Паколькі IP-спісы могуць змяняцца, не варта доўга давяраць старым “ручным” спісам. Калі вы кіруеце VPS або сервер, лепшы падыход — перыядычна аўтаматычна абнаўляць спісы і інтэграваць іх у фаервол ці Apache-include. Калі ваш хостынг — shared, выкарыстоўвайце доступ да логаў, .htaccess і, калі ёсць, бяспекавыя модулі.

Лагіка .htaccess для блакіроўкі фальшывых Googlebot

.htaccess дазваляе ствараць правілы для Apache на ўзроўні каталога: перанакіраванне, кантроль доступу, сцісканне, кэшаванне і базавыя бяспекавыя абмежаванні. Для фальшывых Googlebot задача .htaccess — ацаніць запыт па вызначаных умовах і, калі падазроны, вярнуць 403 Forbidden.

Але ёсць абмежаванне: стандартны .htaccess не ідэальны для рэальнай зваротнай DNS-праверкі ў рэжыме online. У Apache HostnameLookups звычайна выключаны з-за нагрузкі. Таму найбольш практычна ў .htaccess — супастаўляць User-Agent “Googlebot” з IP-allowlist або больш жорстка фільтраваць падазроныя шляхі. Для складанай верыфікацыі лепш выкарыстоўваць WAF, фаервол, CDN або аўтаматызацыю на базе логаў. што такое CDN і як ён уплывае на прадукцыйнасць сайта дапаможа спланаваць такія ўзроўні абароны.

Пакрокавая інструкцыя: як выявіць і заблакіраваць фальшывыя Googlebot

1. Аналізуйце логі доступу

Перад напісаннем правілаў прааналізуйце access log за 24–72 гадзіны. Калі трафік вялікі, гадзіна можа быць дастатковай. Звяртайце ўвагу на IP, дату, URL, код адказу HTTP, памер, referer і User-Agent. Напрыклад, калі адзін IP за 10 хвілін робіць 800 запытаў, большасць вяртаюць 404, а User-Agent “Googlebot” — гэта моцны сігнал падазронасці.

У cPanel і падобных панелях можна спампаваць Raw Access Logs. Калі ёсць SSH, фільтруйце запыты “Googlebot” па IP з дапамогай grep, awk, sort. Мэта — не проста вызначыць кожны User-Agent “Googlebot”, а зразумець паводзіны IP-адрасоў, што выдаюць сябе за Googlebot.

2. Праверце IP, што выдаюць сябе за Googlebot

Знайдзіце падазроныя IP і правядзіце зваротную і прамую DNS-праверку. PTR-запіс тыпу crawl-66-249-66-1.googlebot.com праходзіць першы этап, але дамен павінен вяртаць гэты ж IP пры зваротным рашэнні. Калі PTR няма, дамен іншы або зваротны запыт вяртае іншы IP — гэта не Googlebot.

Гэты крок асабліва важны для SEO-крытычных сайтаў, каб пазбегнуць памылковай блакіроўкі. Калі заблакіраваць сапраўдны Googlebot, новы кантэнт будзе даўжэй індэксавацца, знізіцца свежасць індэксу, з’явяцца памылкі сканавання ў Google Search Console і страты трафіку. Таму блакіроўку выконвайце не на User-Agent, а на выніках верыфікацыі.

3. Спачатку логіруйце, потым блакіруйце

Для бяспекі спачатку назірайце за падазронымі User-Agent і IP. У другой фазе абмежуйце толькі тыя шляхі, што відавочна шкодныя. У трэцяй — блакіруйце запыты з User-Agent “Googlebot”, калі IP не ўваходзіць у Google-спіс.

Гэта асабліва актуальна для e-commerce: памылковае правіла можа ўплываць на аплату, кошык, варыяцыі тавараў ці інтэграцыі складу. Калі сайт з вялікім трафікам — спачатку тэстуйце ў staging. Перанос сайта WordPress і стварэнне тэставай асяроддзя дапаможа бяспечна ўносіць змены ў правілы бяспекі.

Бяспечныя прыклады .htaccess-правілаў

Перад ужываннем прыкладаў праверце сумяшчальнасць Apache, модулей і хостынг-правоў. Apache 2.4 і mod_rewrite — найбольш распаўсюджаныя, але на shared-хостынгу могуць быць абмежаванні. Абавязкова рабіце бэкап .htaccess: адна памылка ў файле — і сайт выдае 500 Internal Server Error.

Просты фільтр паводзін: блакіроўка фальшывых ботаў на важных шляхах

Гэты падыход блакіруе ботаў, што выдаюць сябе за Googlebot, калі яны ідуць на адміністрацыйныя або атакуемыя файлы. Сапраўдны Googlebot не скануе wp-login.php, phpmyadmin ці backup.zip, таму рызыка памылковай блакіроўкі мінімальны.

• 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 гэта не шкодзіць, бо такія URL у індэкс Google не павінны трапляць. Але калі вы карыстаецеся WordPress, правядзіце дадатковую праверку: ці патрэбныя XML-RPC, ці ёсць бяспекавыя плагіны і сэрвісы аддаленай публікацыі.

Лагіка IP-allowlist: супастаўленне User-Agent з афіцыйнымі IP-спісамі

Больш надзейны спосаб — прапускаць запыт з User-Agent “Googlebot” толькі з правераных IP. Прыклад паказвае логіку, IP-спісы трэба браць з актуальнага JSON Google. Старое або няпоўнае спісанне можа заблакіраваць сапраўдны Googlebot.

• 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-дыяпазоны тут прыкладныя. У вытворчасці выкарыстоўвайце аўтаматычна згенераваныя спісы з актуальнага Google JSON. Калі -ipmatch ці Apache expression не падтрымліваюцца, удакладняйце ў хостынг-правайдера. Альтэрнатыва — правілы на CDN/WAF з IP-спісамі.

Зніжэнне падазронай хуткасці запытаў

.htaccess не лепшы інструмент для складанага rate limiting, але можа спыніць некаторыя шкодныя паводзіны. Для рэальнага ліміта выкарыстоўвайце mod_evasive, mod_security, CDN rate limiting або абарону на ўзроўні праграмы. Калі бот робіць больш за 5–10 запытаў у секунду, можа павялічвацца нагрузка на базу дадзеных нават на невялікіх сайтах. Для WordPress дынамічныя старонкі (пошук, катэгорыі, тэгі) часта “вабіцца” ботамі. Тут важна спалучаць robots.txt, canonical, noindex і бяспекавыя правілы. Кіраўніцтва па аптымізацыі хуткасці WordPress закрывае пытанні прадукцыйнасці.

Табліца параўнання: які метад калі выбіраць?

Чэк-ліст: каб не заблакіраваць сапраўдных Googlebot

Галоўны рызыка пры блакіроўцы фальшывых Googlebot — выпадкова заблакіраваць сапраўдных пошукавых ботаў. Пасля кожнай змены правілы прайдзіце такі чэк-ліст:

• Праверце ў Google Search Console, ці няма рэзкага падзення сканавання або росту 403-адказаў.
• У логах пераканайцеся, што сапраўдныя IP Google атрымліваюць 200, 301 ці іншыя нармальныя коды.
• robots.txt не блакіруе Googlebot для важных каталогаў.
• Пратэстуйце sitemap, галоўную, катэгорыі і ключавыя старонкі да і пасля змены .htaccess.
• Дакументуйце крыніцу і дату абнаўлення IP-спісу.

З пункту гледжання тэхнічнага SEO, 403 — моцны сігнал. Калі сапраўдны Googlebot рэгулярна бачыць 403 на важных старонках, сканаванне іх зменшыцца. Таму 403 давайце толькі тым, каго дакладна не хочаце пускаць, і на важных шляхах. Для абмежавання нагрузкі ці часовага абмежавання лепей выкарыстоўваць 429 Too Many Requests, але для простага bot blocking у .htaccess 403 — стандарт і зразумелы.

Дадатковыя меры для WordPress і e-commerce

На WordPress фальшывыя Googlebot часта атакуюць xmlrpc.php, wp-login.php, REST API, пошукавыя URL і архівы аўтараў. У e-commerce — фільтры, запыты склада, кошык, варыяцыі тавараў. Таму важна не толькі блакіраваць тых, хто выдае сябе за Googlebot, але і агульную гігіену ботаў.

• Для ўваходу выкарыстоўвайце двухфактарную аўтэнтыфікацыю і ліміт спробаў.
• Выключайце або абмяжуйце XML-RPC, калі не карыстаецеся.
• Плануйце noindex, canonical і robots.txt для пошукавых і фільтравых URL.
• Выкарыстоўвайце актуальную версію PHP, надзейныя тэмы і плагіны.
• SSL-сертыфікат павінен быць актыўны, усе формы і сесіі праз HTTPS. Hostragons SSL сертыфікаты
• Рэгулярна правярайце DNS-запісы дамена; няправільныя DNS ці слабыя email-запісы — дадатковы рызыка. Праверка дамена і кіраванне DNS

Як шкодны трафік ботаў уплывае на прадукцыйнасць хостынгу?

Боты — гэта не толькі пытанне бяспекі, але і прадукцыйнасці хостынгу. Статычны малюнак запытаць — танна, а пошукавая або фільтраваная старонка ў WordPress ці WooCommerce — гэта дадатковы запыт у базу дадзеных. Калі фальшывы Googlebot робіць 300 дынамічных запытаў у хвіліну, на не кэшаваных старонках PHP воркеры могуць перапоўніцца, а злучэнні з базай дадзеных — вырасці, што запавольвае сайт для рэальных карыстальнікаў.

Прыклад: фільтр тавару спажывае ў сярэднім 250 мс PHP. 600 бот-запытаў у хвіліну — гэта 150 секунд нагрузкі, і калі працэс паралельны, CPU хутка даходзіць да ліміту, TTFB расце. На Core Web Vitals гэта ўплывае на карыстацкі досвед і канверсію. Таму блакіроўка ботаў — задача не толькі бяспекі, але і SEO і аптымізацыі прадукцыйнасці.

Тэставанне: ці працуюць вашы правілы?

Пасля дадання .htaccess-правілаў зробіце тры тэсты. Па-першае, праз звычайны браўзер праверце галоўную, катэгорыі і ўваход. Па-другое, у Google Search Console прайдзіце “Live Test” для важнага URL. Па-трэцяе, у логах праверце, што падазроныя IP з User-Agent “Googlebot” атрымліваюць 403, а сапраўдныя — не блакіруюцца.

З каманднага радка можна выдаваць сябе за Googlebot, каб праверыць, ці спрацоўвае User-Agent-правіла, але гэта не праверка сапраўднасці бота — правярайце IP і DNS. Калі пасля змены атрымалі 500 памылку, значыць, памылка ў .htaccess. Адкатайце апошнія радкі, праверце логі і падтрымку вашага Apache.

План абслугоўвання: як часта абнаўляць правілы?

Блакіроўка ботаў — не аднаразовая задача. Спісы IP Google мяняюцца, шаблоны User-Agent атакуючых таксама, і структура URL сайта можа абнаўляцца. Для малатрафікавых сайтаў дастаткова раз у месяц правяраць логі. Для навінавых, e-commerce або прома-праектаў — лепш штотыдзень. Для вялікіх праектаў аўтаматычны алерт: калі колькасць запытаў з User-Agent “Googlebot” і не пацверджаных IP перавышае парог — дасылаць апавяшчэнне.

.htaccess таксама версіюйце: нават проста бэкап па датах (htaccess-2026-02-15.bak) паскарае адкат. Калі сайт кіруюць некалькі чалавек, дакументуйце змены і матывацыю — гэта зменшыць рызыку перапынення.

Вынік

Засекчы і заблакіраваць фальшывыя Googlebot праз .htaccess, калі ўсё зроблена правільна, абараняе SEO і рэсурсы сервера ад шкодных сканераў. Галоўны прынцып: User-Agent — не доказ; разглядайце IP, DNS, паводзіны і логі разам. Спачатку назірайце, потым блакіруйце нізкарызыковыя шляхі, у фінале — правярайце актуальныя IP-спісы Google.

З інфраструктурай Hostragons — бяспечны хостынг, актуальны SSL, правільны DNS і рэгулярныя бэкапы ў комплексе забяспечваюць стабільны досвед. Можна пачаць з аналізу ботаў на вашым сайце, а пры патрэбе выбраць больш надзейны пакет праз Hostragons пакеты хостынгу.

Частыя пытанні

Ці можа фальшывы Googlebot уплываць на мае пазіцыі ў Google?

Ускосна — так. Калі фальшывы Googlebot забірае рэсурсы сервера, сапраўдны Googlebot і карыстальнікі атрымліваюць больш павольныя адказы. Таксама фальшывы трафік псует аналітыку, што можа вадзіць у зман пры SEO-рашэннях. Правільная блакіроўка захоўвае таргетаваны crawl budget і прадукцыйнасць.

Ці можна проста блакіраваць усе User-Agent “Googlebot” у .htaccess?

Не. Гэта заблакіруе і сапраўдны Googlebot, што прывядзе да праблем з індэксацыяй. Спачатку правярайце IP або DNS, і толькі фальшывыя боты блакіруйце. Найбольш бяспечна — спалучаць allowlist і паводзінныя правілы.

Як часта абнаўляць спісы IP Googlebot?

Для сайтаў з вялікім трафікам — штотыдзень, для малых — раз у месяц. Ідэальна — аўтаматычна з афіцыйных JSON Google. Старое “ручное” спісанне можа выклікаць памылковую блакіроўку сапраўднага Googlebot.

Пасля дадання .htaccess-правілаў атрымалі 500 памылку. Што рабіць?

500 — звычайна вынік сінтаксічнай памылкі, недапушчальнага Apache-правіла або няправільных спецсімвалаў. Адкатайце апошнія радкі, праверце логі і падтрымку Apache 2.4, mod_rewrite і expression. Бэкап .htaccess перад зменамі — абавязкова.

Ці патрэбна .htaccess, калі выкарыстоўваю CDN або WAF?

CDN ці WAF — моцны ўзровень абароны ад ботаў, але .htaccess застаецца дадатковым і блізкім да праграмы бар’ерам. Лепшы вынік — rate limiting і bot-верыфікацыя на CDN/WAF, а на серверы — абмежаванні для важных шляхоў праз .htaccess.