تقوم زواحف الذكاء الاصطناعي بتضخيم أرقام الزيارات لديك، والطريقة المختصرة المعتادة — وهي التحقق من ترويسة User-Agent — لا تكتشف ذلك.
كشف مسح حديث للسجلات استمر لمدة ثمانية أيام عن 468 عملية جلب حقيقية للمقالات، ولكن مقابل 991 طلبًا تظاهرت بأنها بوتات ذكاء اصطناعي بينما كانت في الواقع تبحث عن ملفات مثل .env أو .git. المسبب؟ يمكن لأي شخص إدراج سلسلة User-Agent معلنة ذاتيًا مثل GPTBot أو ChatGPT-User في طلب HTTP.
لماذا تهم هذه المقاييس
تتعامل المواقع الإلكترونية مع الزيادة المفاجئة في "زيارات الذكاء الاصطناعي" كعلامة على الأهمية والانتشار. وتستخدم هذه الأرقام لتبرير أسعار الإعلانات، وتخصيص موارد الخادم، والتفاخر أمام المستثمرين. وعندما تكون نصف زيارات الذكاء الاصطناعي المبلغ عنها مجرد ضجيج، تذهب الميزانيات في غير محلها وتصبح لوحات البيانات مضللة.
الفلتران اللذان يفصلان بين الادعاء والواقع
verifiedBotCategoryالخاص بـ Cloudflare – لا تملأ Cloudflare هذا الحقل إلا بعد ربط عنوان IP الخاص بالطلب بنطاق بوت معروف عبر DNS العكسي (reverse DNS). إذا كانت الترويسة تقول "GPTBot" ولكن عنوان IP فشل في عملية البحث، فإن الطلب يقع في فئة "غير موثق" (unverified).- التحقق المتقاطع مع خريطة الموقع (Sitemap) – لا يقرأ البوت محتواك حقًا إلا عندما يظهر عنوان URL المطلوب في خريطة الموقع XML الخاصة بك. الطلبات لمسارات غير موجودة في خريطة الموقع من المرجح أنها تبحث عن ثغرات أمنية بدلاً من فهرسة المقالات.
أدى تطبيق كلا الفلترين على نفس العينة التي استمرت ثمانية أيام إلى نتائج صارخة:
- ChatGPT-User – 39% من الطلبات اجتازت التحقق.
- GPTBot – 13% تم التحقق منها.
- PerplexityBot – 0% تم التحقق منها.
- Google-Extended – 0% تم التحقق منها؛ هذه السلسلة لا تتوافق مع أي زاحف رسمي من Google.
حتى بين المكالمات التي تم التحقق منها، قامت العديد من البوتات بجلب robots.txt فقط أو خريطة الموقع نفسها، وليس صفحات المقالات التي تهمك.
ما يمكن للمطورين فعله اليوم
- تفعيل التحقق من البوتات في Cloudflare في مسار التحليلات الخاص بك. يظهر حقل
verifiedBotCategoryفي ترويسات الطلب ويمكن تخزينه جنبًا إلى جنب مع سجلاتك الخاصة. - الحفاظ على خريطة موقع (sitemap) محدثة وأتمتة عملية التحقق من وجود مسار كل طلب وارد هناك قبل احتسابه كمشاهدة للمحتوى.
- تصفية طرق الطلب غير التابعة لـ GET والطلبات التي تستهدف ملفات التطوير النموذجية (
.env,.git,.bak). هذه الطلبات تكون دائمًا تقريبًا عمليات مسح خبيثة.
وجهة النظر المعارضة
يجادل البعض بأن عمليات التحقق من DNS العكسي يمكن تزييفها، وأن الغرض المشروع للبوت قد يكون اكتشاف عناوين URL جديدة لم تُدرج بعد في خريطة الموقع. هذه المخاوف مشروعة: يمكن لمهاجم مصمم اختراق سجل DNS، وسيكون المحتوى الجديد غائبًا بطبيعة الحال عن خريطة الموقع الحالية حتى دورة التوليد التالية.
الرد العملي هو التعامل مع التحقق كدرجة ثقة بدلاً من كونه بوابة مطلقة. ادمج بين التحقق من DNS، ووجود المسار في خريطة الموقع، والتحقق من طريقة الطلب لرفع المعايير لما تحتسبه "زيارات ذكاء اصطناعي حقيقية". إذا اجتاز الطلب اثنين من ثلاثة فحوصات، فقم بتمييزه للمراجعة اليدوية بدلاً من استبعاده تمامًا.
ما يجب مراقبته لاحقًا
- التغييرات في واجهة برمجة تطبيقات التحقق من Cloudflare – أي تغيير في منطق
verifiedBotCategoryقد يؤدي إلى تغيير معدلات التحقق. - ظهور بوتات جديدة تُعرف نفسها ذاتيًا – راقب سلاسل User-Agent التي تظهر في سجلاتك؛ فقد يشير الارتفاع المفاجئ إلى ماسح ضوئي جديد يتنكر في زي زاحف ذكاء اصطناعي.
- تكرار إنشاء خريطة الموقع – الفترات الطويلة تزيد من احتمال تصنيف الزواحف المشروعة بشكل خاطئ.
الخلاصة بسيطة: توقف عن التعامل مع سلسلة User-Agent كدليل. اعتمد طبقات من التحقق عبر DNS والتحقق من خريطة الموقع، وستحصل على صورة أوضح لمن يقرأ محتواك بالفعل.
المصدر: https://dev.to/aulvem/ai-crawler-user-agents-are-self-reported-468-real-fetches-991-fake-ones-bgo