تحليل سجلات الخادم لزواحف الذكاء الاصطناعي: من زار فعلاً
تحليل سجلات الخادم يقرأ وكيل المستخدم وعنوان IP اللذين يحتفظ بهما الخادم، ثم يتحقق من الهوية قبل العد. يتضمن الأمر وجدول الحقول وقائمة الرموز وحدود ما يثبته السجل.

تحليل سجلات الخادم يعني قراءة حقلين يحتفظ بهما الخادم أصلًا: وكيل المستخدم وعنوان IP. ثم فصل الطلبات التي جاءت من زاحف ذكاء اصطناعي حقيقي عن التي تدّعي ذلك فقط. هذا التحليل يجيب عن سؤال لا يجيب عنه اختبار الوصول: لا «هل كان GPTBot يستطيع الوصول إلى الصفحة»، بل «هل وصل، وفي أي يوم، وكم مرة». رمز 200 يثبت أن الباب يُفتح. السجل يثبت من دخله.
ما يقوله تحليل سجلات الخادم وما لا يقوله
يقول أي الوكلاء طلب أي مسار، وفي أي وقت، وبأي رمز حالة، ومن أي عنوان IP. ولا يقول هل استُخدم المحتوى بعد ذلك في إجابة أو في تدريب. ولا يؤكد الهوية وحده: وكيل المستخدم تصريح ذاتي، وأي شخص يستطيع نسخه. مطابقة IP هي وحدها التي تحوّل «طلب يقول GPTBot» إلى «GPTBot».
لهذا السبب يستحق الموضوع طريقة عمل لا حيلة من سطر واحد. سطر السجل له نصفان. النصف الذي يقرأه الجميع هو الوكيل. والنصف الذي يحدد صدق السطر هو عنوان IP.
قبل البدء تحتاج صلاحية قراءة لسجل الخادم وطرفية. إذا لم تكن الاستضافة تعطيك سجلات، فلا بديل لهذه الطريقة: لا أداة خارجية ترى طلبات لم تصل إلى خادمك أصلًا.
لماذا يتفوق السجل على فحص الوكيل
اختبار الوصول يرسل طلبًا بوكيل مقلّد ويراقب الاستجابة. السجل يسجل ما فعله عملاء حقيقيون دون استثارة. وقد يختلف الاثنان في الاتجاهين: الوصول ليس زيارة، وفشل الاختبار لا يمنع مرور زاحف من مسار آخر.
ويمنح السجل حقلًا لا ينتجه أي اختبار: الوقت. الاختبار يعطي نعم أو لا في لحظة. السجل يعطي عددًا يوميًا لكل روبوت، وهي الطريقة الوحيدة للتمييز بين زاحف أسبوعي وآخر جاء مرة ثم غادر.
نفّذ بهذا الترتيب
خمس خطوات، ولكل خطوة شرط إتمام قبل الانتقال إلى التالية.
- اعثر على السجل وأكّد صيغته. الصيغة الافتراضية في nginx هي
combined، وفي Apache توثّق صيغة NCSA الممتدة/combined الحقول%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i". تنتهي الخطوة حين تستطيع تسمية كل حقل في سطر حقيقي. - عدّ حسب الوكيل قبل التصفية. في سطر combined يكون الحقل السادس بين علامتي الاقتباس هو الوكيل. تنتهي حين تملك قائمة بأكثر ثلاثين وكيلًا، لا فقط الوكلاء الذين توقعتهم.
- استخرج رموز زواحف الذكاء الاصطناعي. السلاسل الدقيقة في الجدول أدناه. تنتهي حين يصبح لكل رمز عدد طلبات وتاريخ أول ظهور.
- تحقق من عناوين IP التي تنوي تصديقها. DNS عكسي ثم أمامي لـ Google، وملفات JSON المنشورة لـ OpenAI. تنتهي حين يكون كل سطر ستقتبسه موثقًا أو موسومًا بأنه غير محقق.
- سجّل النافذة، لا الإجمالي فقط. عدد بلا عدد أيام لا معنى له. تنتهي حين تقول الملاحظة «412 طلبًا، من 1 إلى 31 أغسطس 2026، 5 مواقع».
المخرج: أمر واحد وجدولان
هذا الأمر يحول سجلًا بصيغة combined إلى عدد لكل وكيل. يفترض عدم وجود علامات اقتباس مهروبة داخل حقل الوكيل، وهو صحيح للزواحف أدناه وغير صحيح لبعض الكاشطات.
awk -F'"' '{print $6}' access.log \
| sed 's/;.*compatible;//' \
| sort | uniq -c | sort -rn | head -30
خطوة sed موجودة لأن المتصفحات تخفي الرمز الحقيقي خلف بادئة توافق. احتفظ أيضًا بالحقل السادس الخام لتعود إليه عندما يبدو العدد غريبًا.
المخرج الثاني جدول الحقول. معظم الناس يعرفون الوكيل ويتوقفون عنده، ولهذا تفوتهم المسارات في المرور الأول.
| الحقل | مثال | ما يقوله |
|---|---|---|
| العنوان البعيد | 66.249.66.1 | الحقل الوحيد القابل للتحقق من قائمة منشورة |
| سطر الطلب | GET /pricing HTTP/1.1 | الطريقة والمسار المطلوبان |
| الحالة | 200 | هل وصل المحتوى أم وصل حجب |
| البايتات المرسلة | 18432 | كم أُعيد فعليًا |
| المُحيل | - | غالبًا فارغ تمامًا مع الزواحف |
| وكيل المستخدم | ... GPTBot/1.4 ... | التصريح، قابل للتزوير، ومُفرط في تصديقه |
المخرج الثالث قائمة الرموز التي ينشرها المشغلون، وأُعيدت قراءتها في 22 سبتمبر 2026 من وثائقهم. ليست كاملة، وتظهر رموز جديدة دون إشعار، ولهذا تعد الخطوة 2 كل شيء قبل التصفية.
| الرمز | المشغل | الغرض | التحقق |
|---|---|---|---|
GPTBot | OpenAI | زحف للتدريب | نعم عبر openai.com/gptbot.json |
OAI-SearchBot | OpenAI | إظهار في البحث | نعم عبر openai.com/searchbot.json |
ChatGPT-User | OpenAI | طلب يبدأه إنسان | نعم عبر openai.com/chatgpt-user.json |
Googlebot | زحف للبحث | DNS عكسي وأمامي، وملفات JSON | |
Google-Extended | رمز تحكم | لا: لا يرسل طلبات خاصة به | |
ClaudeBot | Anthropic | زحف | موثق، راجع النطاقات في صفحتهم |
PerplexityBot | Perplexity | زحف | موثق، راجع النطاقات في صفحتهم |
صفان يحملان الفكرة. Google-Extended رمز تحكم لا زاحف: توثيق Google يذكر أنه لا يملك سلسلة وكيل مستقلة، لذا غيابه من السجل ليس فشلًا. وChatGPT-User يبدأه شخص، لذا طلباته ليست زحفًا تلقائيًا.
ما يفسد النتيجة
الثقة بالوكيل. هذا هو الخطأ الافتراضي، وينتج إجابة واثقة وخاطئة. تحقق Google يتطلب استعلامي DNS: عكسي على IP، ثم أمامي على الاسم الناتج، مع وجوب التطابق. ولـ OpenAI تقارن IP بملف النطاقات المنشور. ولزاحف لا ينشر أيًا منهما، اكتب «غير محقق» بدل أن تصدق أو تحذف العدد.
عدّ قراءات robots.txt كصفحات. تذكر OpenAI أنها قد تضيف علامة إلى الوكيل عند قراءة robots.txt للتمييز بين هذه الطلبات وغيرها. إذا كانت صيغة السجل تحذف المسار، تصبح قراءة robots.txt وقراءة صفحة متطابقتين. افصل بالمسار قبل أن تعلن عدد زحف.
قراءة نافذة قصيرة. سبعة أيام لا تجيب سؤال ثلاثين يومًا، وتدوير السجلات يقطع النافذة دون تحذير. اذكر أول وآخر طابع زمني عددته فعلًا.
أسئلة شائعة
هل يمكن الوثوق بوكيل المستخدم في السجل؟
لا. عامله كتصريح حتى يطابق IP نطاقًا منشورًا أو ينجح في DNS العكسي والأمامي. السجل وثيقة، وليس إثبات هوية.
كيف أعرف أن GPTBot زار موقعي؟
ابحث عن رمز GPTBot، ثم طابق كل IP مع openai.com/gptbot.json. رمز بلا IP مطابق هو طلب آخر نسخ الاسم.
كم يومًا من السجل أحتاج؟
ما يكفي لتغطية دورة زحف كاملة، وهو يختلف بحسب الموقع ولا رقم عالمي له. ثلاثون يومًا نقطة بداية معقولة. إذا كان لديك سبعة أيام فقل ذلك: النافذة القصيرة تقلل العدد ولا ترفعه أبدًا.
الحد الذي يستحق الكتابة صراحة: السجل يثبت حدوث طلب، ولا يثبت أن المحتوى استُخدم أو رُتب أو اقتُبس. وحين تريد تحويل هذا السجل إلى إجراء منشور، فهنا يعمل QueryWin. وللتحقق أولًا من إمكانية وصول الزواحف، ابدأ بـالتحقق من قراءة الذكاء الاصطناعي لموقعك. وإن كان السؤال أي الروبوتات تسمح بها، فالجواب في robots.txt لزواحف الذكاء الاصطناعي.
الوكيل يقدّم نفسه. وعنوان IP يقرر إن كان صادقًا.
جزء من دليل QueryWin · المستوى 2


