AI کرالرز آپ کے ٹریفک کے اعداد و شمار کو بڑھا رہے ہیں، اور عام شارٹ کٹ—User-Agent ہیڈر کو چیک کرنا—اسے نہیں پکڑ پاتا۔

حال ہی میں آٹھ دن کے لاگ (log) کے جائزے میں 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 سائٹ میپ میں موجود ہو۔ وہ درخواستیں جو سائٹ میپ میں موجود نہیں ہیں، وہ غالباً آرٹیکلز کو انڈیکس کرنے کے بجائے کمزوریوں (vulnerabilities) کی تلاش کر رہی ہوتی ہیں۔

ایک ہی آٹھ دن کے نمونے پر دونوں فلٹرز کا اطلاق کرنے سے یہ واضح اعداد و شمار سامنے آئے:

  • ChatGPT-User – 39% درخواستیں تصدیق میں کامیاب رہیں۔
  • GPTBot – 13% تصدیق شدہ۔
  • PerplexityBot – 0% تصدیق شدہ۔
  • Google-Extended – 0% تصدیق شدہ؛ یہ اسٹرنگ کسی بھی سرکاری گوگل کرالر سے مطابقت نہیں رکھتی۔

تصدیق شدہ کالز میں بھی، بہت سے بوٹس نے صرف robots.txt یا خود سائٹ میپ کو فیچ کیا، ان آرٹیکل صفحات کو نہیں جن کی آپ کو ضرورت ہے۔

ڈویلپرز آج کیا کر سکتے ہیں

  • اپنے اینالیٹکس پائپ لائن میں Cloudflare بوٹ تصدیق (bot verification) کو فعال کریں۔ verifiedBotCategory فیلڈ درخواست کے ہیڈرز میں نظر آتی ہے اور اسے آپ کے اپنے لاگز کے ساتھ محفوظ کیا جا سکتا ہے۔
  • ایک اپ ٹو ڈیٹ سائٹ میپ برقرار رکھیں اور ایک خودکار چیک (automate) بنائیں کہ ہر آنے والی درخواست کا پاتھ وہاں موجود ہے یا نہیں، اس سے پہلے کہ آپ اسے مواد کے ویو (content view) کے طور پر گنیں۔
  • غیر GET طریقوں (non-GET methods) اور ایسی درخواستوں کو فلٹر کریں جو عام ڈویلپمنٹ فائلوں (.env, .git, .bak) کو نشانہ بناتی ہیں۔ وہ تقریباً ہمیشہ بدنیتی پر مبنی اسکینز ہوتے ہیں۔

دوسرا پہلو

کچھ لوگوں کا کہنا ہے کہ ریورس DNS چیک کو دھوکہ دیا جا سکتا ہے (spoof کیا جا سکتا ہے)، اور ایک بوٹ کا جائز مقصد ان نئے URLs کو تلاش کرنا ہو سکتا ہے جو ابھی تک سائٹ میپ میں شامل نہیں ہیں۔ یہ خدشات درست ہیں: ایک پرعزم حملہ آور DNS ریکارڈ کے ساتھ چھیڑ چھاڑ کر سکتا ہے، اور نیا مواد قدرتی طور پر اگلے جنریشن سائیکل تک موجودہ سائٹ میپ میں موجود نہیں ہوگا۔

عملی جواب یہ ہے کہ تصدیق کو ایک حتمی دروازے کے بجائے اعتماد کے اسکور (confidence score) کے طور پر دیکھا جائے۔ DNS تصدیق، سائٹ میپ کی موجودگی، اور درخواست کے طریقے (request-method) کے چیک کو ملا کر اس معیار کو بلند کریں جسے آپ "حقیقی AI ٹریفک" کے طور پر شمار کرتے ہیں۔ اگر کوئی درخواست تین میں سے دو چیک پاس کر لیتی ہے، تو اسے مکمل طور پر مسترد کرنے کے بجائے دستی نظرثانی (manual review) کے لیے نشان زد کریں۔

آگے کیا نظر رکھنا ہے

  • Cloudflare کی تصدیق کرنے والی API میں تبدیلیاں – verifiedBotCategory کے لاجک میں کوئی بھی تبدیلی تصدیق کی شرح کو بدل سکتی ہے۔
  • نئے خود ساختہ بوٹس کا ظہور – اپنے لاگز میں نظر آنے والی User-Agent اسٹرنگز پر نظر رکھیں؛ اچانک اضافہ ایک نئے اسکینر کی نشاندہی کر سکتا ہے جو AI کرالر کا روپ دھارے ہوئے ہو۔
  • سائٹ میپ بنانے کی تعدد (frequency) – طویل وقفے اس امکان کو بڑھا دیتے ہیں کہ جائز کرالرز کو غلط درجہ بندی کا سامنا کرنا پڑے۔

خلاصہ سادہ ہے: User-Agent اسٹرنگ کو ثبوت کے طور پر لینا بند کریں۔ DNS تصدیق اور سائٹ میپ کی تصدیق کی تہیں (layers) استعمال کریں، اور آپ کو ایک واضح تصویر نظر آئے گی کہ اصل میں آپ کا مواد کون پڑھ رہا ہے۔

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