AI क्रॉलर्स आपके ट्रैफिक के आंकड़ों को बढ़ा रहे हैं, और सामान्य शॉर्टकट—User-Agent हेडर की जांच करना—इसे पकड़ नहीं पाता है।

हाल ही में आठ दिनों के लॉग विश्लेषण (log sweep) में 468 वास्तविक लेख फेच (fetches) मिले, लेकिन 991 ऐसे अनुरोध मिले जिन्होंने वास्तव में AI बॉट होने का ढोंग किया, जबकि वे असल में .env या .git जैसी फाइलों की जांच कर रहे थे। इसका कारण? कोई भी HTTP अनुरोध में GPTBot या ChatGPT-User जैसी स्वयं घोषित User-Agent स्ट्रिंग डाल सकता है।

यह मेट्रिक क्यों मायने रखता है

वेबसाइटें "AI ट्रैफिक" में उछाल को प्रासंगिकता के संकेत के रूप में देखती हैं। वे इन आंकड़ों का उपयोग विज्ञापन दरों को सही ठहराने, सर्वर संसाधनों को आवंटित करने और निवेशकों को दिखाने के लिए करती हैं। जब रिपोर्ट किए गए AI हिट्स में से आधा केवल शोर (noise) होता है, तो बजट भटक जाते हैं और डैशबोर्ड भ्रामक हो जाते हैं।

दो फ़िल्टर जो दावे और वास्तविकता को अलग करते हैं

  1. Cloudflare का verifiedBotCategory – Cloudflare इस फ़ील्ड को केवल तभी भरता है जब वह रिवर्स DNS के माध्यम से अनुरोध के IP को किसी ज्ञात बॉट डोमेन से जोड़ लेता है। यदि हेडर "GPTBot" कहता है लेकिन IP लुकअप विफल हो जाता है, तो अनुरोध "unverified" (अपुष्ट) श्रेणी में चला जाता है।
  2. Sitemap क्रॉस-चेक – एक बॉट वास्तव में आपके कंटेंट को तभी पढ़ता है जब अनुरोधित URL आपके XML साइटमैप में दिखाई देता है। साइटमैप में अनुपस्थित पथों (paths) के लिए किए गए अनुरोध लेखों को इंडेक्स करने के बजाय संभवतः कमजोरियों (vulnerabilities) की तलाश करते हैं।

उसी आठ-दिवसीय नमूने पर दोनों फ़िल्टर लागू करने से चौंकाने वाले आंकड़े सामने आए:

  • ChatGPT-User – 39% अनुरोधों ने सत्यापन (verification) पास किया।
  • GPTBot – 13% सत्यापित।
  • PerplexityBot – 0% सत्यापित।
  • Google-Extended – 0% सत्यापित; यह स्ट्रिंग किसी भी आधिकारिक Google क्रॉलर से मेल नहीं खाती है।

सत्यापित कॉल्स में भी, कई बॉट्स ने केवल robots.txt या स्वयं साइटमैप को ही फेच किया, उन लेखों के पेजों को नहीं जिनकी आपको परवाह है।

डेवलपर्स आज क्या कर सकते हैं

  • अपने एनालिटिक्स पाइपलाइन में Cloudflare बॉट वेरिफिकेशन सक्षम करें। verifiedBotCategory फ़ील्ड अनुरोध हेडर में दिखाई देता है और इसे अपने स्वयं के लॉग के साथ संग्रहीत किया जा सकता है।
  • एक अपडेटेड साइटमैप बनाए रखें और एक ऑटोमेटेड चेक रखें कि किसी भी इनकमिंग अनुरोध का पथ उसे कंटेंट व्यू के रूप में गिनने से पहले वहां मौजूद है या नहीं।
  • Non-GET मेथड्स और उन अनुरोधों को फ़िल्टर करें जो विशिष्ट डेवलपमेंट फाइलों (.env, .git, .bak) को लक्षित करते हैं। वे लगभग हमेशा दुर्भावनापूर्ण स्कैन (malicious scans) होते हैं।

दूसरा पक्ष (The counter-point)

कुछ लोगों का तर्क है कि रिवर्स DNS चेक को स्पूफ (spoof) किया जा सकता है, और एक बॉट का वैध उद्देश्य उन नए URL को खोजना हो सकता है जो अभी तक साइटमैप में सूचीबद्ध नहीं हैं। ये चिंताएं वाजिब हैं: एक दृढ़ हमलावर DNS रिकॉर्ड से समझौता कर सकता है, और नया कंटेंट अगले जनरेशन साइकिल तक स्वाभाविक रूप से वर्तमान साइटमैप में अनुपस्थित रहेगा।

व्यावहारिक प्रतिक्रिया यह है कि सत्यापन को एक पूर्ण द्वार (absolute gate) के बजाय एक कॉन्फिडेंस स्कोर (confidence score) के रूप में माना जाए। जिसे आप "वास्तविक AI ट्रैफिक" मानते हैं, उसके मानक को ऊंचा करने के लिए DNS सत्यापन, साइटमैप उपस्थिति और अनुरोध-मेथड चेक को मिलाएं। यदि कोई अनुरोध तीन में से दो चेक पास कर लेता है, तो उसे सीधे खारिज करने के बजाय मैन्युअल समीक्षा के लिए चिह्नित करें।

आगे क्या देखें

  • Cloudflare के वेरिफिकेशन API में बदलाव – verifiedBotCategory लॉजिक में किसी भी बदलाव से सत्यापन दर बदल सकती है।
  • नए स्वयं-पहचाने जाने वाले बॉट्स का उदय – अपने लॉग में दिखाई देने वाली User-Agent स्ट्रिंग्स पर नज़र रखें; अचानक उछाल एक नए स्कैनर का संकेत दे सकता है जो AI क्रॉलर का रूप धारण कर रहा है।
  • Sitemap जनरेशन की आवृत्ति – लंबे अंतराल से इस बात की संभावना बढ़ जाती है कि वैध क्रॉलर्स को गलत वर्गीकृत किया जा सकता है।

निष्कर्ष सरल है: User-Agent स्ट्रिंग को प्रमाण मानना बंद करें। DNS सत्यापन और साइटमैप वैलिडेशन की परतें जोड़ें, और आप स्पष्ट रूप से देख पाएंगे कि वास्तव में आपका कंटेंट कौन पढ़ रहा है।

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