AI crawlers vinavikuza namba zako za trafiki, na njia ya kawaida ya mkato—kuangalia kichwa cha User-Agent—haizikamati.

Uchunguzi wa kumbukumbu (logs) wa siku nane hivi hivi uligundua upataji halisi wa makala 468 lakini maombi 991 yalijifanya kuwa roboti za AI wakati kwa kweli yalikuwa yakitafuta mafaili kama .env au .git. Sababu? Mtu yeyote anaweza kuingiza mfululizo wa User-Agent kama GPTBot au ChatGPT-User kwenye ombi la HTTP.

Kwa nini kipimo hiki ni muhimu

Tovuti huchukulia ongezeko la “trafiki ya AI” kama ishara ya umuhimu. Wanatumia namba hizo kuhalalisha viwango vya matangazo, kutenga rasilimali za seva, na kujivuna kwa wawekezaji. Wakati nusu ya hits za AI zinazoripotiwa ni kelele tu, bajeti zinapotea na dashibodi zinakuwa za upotoshaji.

Vichujio viwili vinavyotofautisha madai na ukweli

  1. verifiedBotCategory ya Cloudflare – Cloudflare hujaza uwanja huu tu baada ya kutatua IP ya ombi na kuilinganisha na domain inayojulikana ya roboti kupitia reverse DNS. Ikiwa kichwa (header) kinasema “GPTBot” lakini IP inashindwa kutafutwa, ombi hilo huangukia kwenye kundi la “zisizothibitishwa”.
  2. Ukaguzi wa sitemap – Roboti inasoma maudhui yako kikweli tu wakati URL inayoomba inaonekana kwenye sitemap yako ya XML. Maombi ya njia (paths) ambazo hazipo kwenye sitemap huenda yanatafuta udhaifu wa kiusalama badala ya kuorodhesha makala.

Kutumia vichujio vyote viwili kwenye sampuli ile ile ya siku nane kulitoa namba za kushtua:

  • ChatGPT-User – 39% ya maombi yalipita uhakiki.
  • GPTBot – 13% zilithibitishwa.
  • PerplexityBot – 0% zilithibitishwa.
  • Google-Extended – 0% zilithibitishwa; mfululizo huo haulingani na kichambuzi chochote rasmi cha Google.

Hata miongoni mwa simu zilizothibitishwa, roboti nyingi zilipata tu robots.txt au sitemap yenyewe, na si kurasa za makala unazozijali.

Nini watengenezaji (developers) wanaweza kufanya leo

  • Washa uhakiki wa roboti wa Cloudflare katika mchakato wako wa uchambuzi (analytics pipeline). Uwanja wa verifiedBotCategory unaonekana kwenye vichwa vya maombi na unaweza kuhifadhiwa pamoja na kumbukumbu (logs) zako.
  • Weka sitemap iliyosasishwa na otomatisha ukaguzi kwamba kila njia ya ombi linaloingia ipo hapo kabla ya kuhesabu kama mtazamo wa maudhui.
  • Chuja mbinu zisizo za GET na maombi yanayolenga mafaili ya kawaida ya maendeleo (.env, .git, .bak). Hayo mara nyingi ni ukaguzi wa nia mbaya.

Upande wa pili

Baadhi wanahoji kuwa ukaguzi wa reverse DNS unaweza kudanganywa (spoofed), na kwamba madhumuni halali ya roboti yanaweza kuwa kugundua URL mpya ambazo bado hazijaorodheshwa kwenye sitemap. Wasiwasi huo ni wa msingi: mshambuliaji aliyejitolea anaweza kuingilia rekodi ya DNS, na maudhui mapya kwa asili hayatakuwepo kwenye sitemap ya sasa hadi mzunguko ujao wa kutengeneza.

Jibu la kimantiki ni kuchukulia uhakiki kama alama ya uaminifu (confidence score) badala ya kizuizi cha moja kwa moja. Unganisha uhakiki wa DNS, uwepo kwenye sitemap, na ukaguzi wa mbinu ya ombi ili kuongeza kiwango cha kile unachokihesabu kama “trafiki halisi ya AI.” Ikiwa ombi litapita ukaguzi miwili kati ya mitatu, liweke kwenye orodha ya mapitio ya mwongozo badala ya kulitupa moja kwa moja.

Nini cha kufuatilia baadaye

  • Mabadiliko katika API ya uhakiki ya Cloudflare – mabadiliko yoyote katika mantiki ya verifiedBotCategory yanaweza kubadilisha viwango vya uhakiki.
  • Kutokea kwa roboti mpya zinazojitambulisha zenyewe – angalia mfululizo wa User-Agent unaotokea kwenye kumbukumbu zako; ongezeko la ghafla linaweza kuashiria skana mpya inayojifanya kuwa AI crawler.
  • Marudio ya kutengeneza sitemap – vipindi virefu vinaongeza nafasi kwamba vichambuzi halali vitatambuliwa vibaya.

Funzo ni rahisi: acha kuchukulia mfululizo wa User-Agent kama ushahidi. Ongeza tabaka la uhakiki wa DNS na uthibitishaji wa sitemap, na utaona picha iliyo wazi zaidi ya nani anayesoma maudhui yako kikweli.

Source: https://dev.to/aulvem/ai-crawler-user-agents-are-self-reported-468-real-fetches-991-fake-ones-bgo