لن ترى GPTBot أبداً في Google Analytics. يعتمد GA4 ومعظم أدوات التحليل الخارجية على تنفيذ JavaScript داخل المتصفح لتسجيل الزيارة، بينما لا يشغّل GPTBot لغة JS ولا يفعّل شيفرة التتبع. لذلك، إذا أردت إثبات أن زاحف OpenAI دخل صفحتك فعلاً، ومعرفة ما جلبه ونوع الاستجابة التي تلقاها، فلن تجد دليلاً موثوقاً سوى سجل الوصول الأصلي للخادم.
لماذا تمثل سجلات الخادم الحقيقة الوحيدة؟
يسلك زاحف الذكاء الاصطناعي مساراً مختلفاً تماماً عن المستخدم الحقيقي. يفتح الشخص المتصفح ويحمّل الصفحة وينفّذ JS، فتُطلق فعالية GA4 وتظهر الزيارة على لوحة المعلومات. أما زاحف مثل GPTBot، فيرسل طلب HTTP ويجمع محتوى HTML المستلم ثم يغادر، من دون تنفيذ شيفرة التتبع؛ ولهذا لا ترصده أدوات التحليل إطلاقاً. سجلات الخادم تعمل بطريقة مختلفة: فمع كل طلب وارد، سواء صدر عن شخص أو Googlebot أو GPTBot، يسجّل Nginx أو Apache عنوان IP المصدر، والوقت، ومسار الطلب، ورمز حالة الاستجابة، وUser-Agent، سطراً بعد سطر. لا تستطيع الواجهة الأمامية منع إنشاء هذا السجل، ولا يختفي لمجرد أن الطرف الآخر لا يشغّل JS.
تعرّف أولاً إلى زواحف OpenAI الثلاثة، ولا تحصر بحثك في GPTBot
يفترض كثيرون أن OpenAI تستخدم زاحفاً واحداً، فيبحثون داخل السجل عن GPTBot وحده ويقلّلون بذلك كثيراً من تقدير مستوى ظهورهم. لدى OpenAI ما لا يقل عن ثلاثة زواحف، لكل منها غرض مختلف وUser-Agent خاص به. لذا ينبغي التعامل معها واحتساب طلباتها بصورة منفصلة.
- GPTBot: يجلب المحتوى لأغراض تدريب النماذج وتحسينها، ويتضمن User-Agent الخاص به "GPTBot". يلتزم بتوجيهات robots.txt، وتنشر OpenAI عناوين IP المصدر على openai.com/gptbot.json.
- OAI-SearchBot: ينشئ فهرساً لوظيفة البحث داخل ChatGPT، ويتضمن User-Agent الخاص به "OAI-SearchBot". وهو الأكثر ارتباطاً بصورة مباشرة بظهور موقعك كمصدر «مُستشهد به» في إجابات ChatGPT.
- ChatGPT-User: يعمل عندما يطلب مستخدم قراءة رابط داخل ChatGPT، ويتضمن User-Agent الخاص به "ChatGPT-User". ظهوره يعني أن شخصاً حقيقياً يصل إلى صفحتك عبر ChatGPT.
- ولنظرة أشمل: غالباً ما تجد في السجل نفسه زواحف ذكاء اصطناعي أخرى مثل PerplexityBot وClaudeBot وGoogle-Extended وغيرها، ويمكن تحليلها بالطريقة ذاتها تماماً.
الخطوة 1: اعثر على آثار GPTBot في سجل الوصول
لنأخذ تنسيق Nginx combined الشائع مثالاً. يعرض كل سطر في السجل عنوان IP المصدر، والوقت، و"GET /blog/geo-audit HTTP/1.1"، ورمز الحالة 200، وحجم البيانات المُعادة، ثم سلسلة User-Agent. وفي طلبات GPTBot، ستجد في نهاية User-Agent العبارة compatible; GPTBot/1.2; +https://openai.com/gptbot. بالاعتماد على هذه العلامة، يمكنك كشف سلوكه ببضعة أوامر فقط.
- استخراج جميع طلبات GPTBot: grep -i "GPTBot" /var/log/nginx/access.log
- حساب عدد زياراته اليوم: grep -ic "GPTBot" access.log
- عرض توزيع رموز حالة الاستجابة (العمود 9 في تنسيق combined هو رمز حالة HTTP): grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- معرفة الصفحات التي يجلبها أكثر من غيرها (العمود 7 هو مسار الطلب): grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- مقارنة حجم زحف الزواحف الثلاثة دفعة واحدة: grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
تكشف النتائج فوراً ثلاثة أمور: التكرار، أي عدد الزيارات يومياً وأوقاتها؛ والتغطية، أي ما إذا كان الزاحف يصل إلى أهم صفحات المنتجات والمقالات أم يدور حول الصفحة الرئيسية فقط؛ وسلامة الاستجابة، أي ما إذا كان رمز الحالة 200 في معظم الطلبات. إذا لم يُظهر grep أي نتيجة، فهذا يعني أن GPTBot لم يزر الموقع خلال الفترة التي يغطيها السجل. عندها راجع robots.txt والجدار الناري لمعرفة ما إذا كان أحدهما يمنعه.
الخطوة 2: تأكد من أن GPTBot الذي وجدته حقيقي
يمكن تزوير سلسلة User-Agent بسهولة. يستطيع أي زاحف، بل حتى الزيارات الضارة، وضع "GPTBot" في الترويسة لانتحال هويته، سواء لتجاوز قواعد معينة أو لاستهلاك موارد خادمك. لذلك لا يكفي اكتشاف الطلب؛ بل يجب التحقق من مصدره. وهناك طريقتان موثوقتان للغاية لإجراء ذلك.
- المقارنة مع قائمة IP الرسمية: تنشر OpenAI نطاقات عناوين IP المصدر لكل زاحف على openai.com/gptbot.json وopenai.com/searchbot.json وopenai.com/chatgpt-user.json. قارن عنوان IP المسجّل بالنطاق المخصص للزاحف، ولا تحتسب الطلب إلا إذا كان ضمنه.
- التحقق عبر DNS العكسي: نفّذ استعلام PTR لعنوان IP المصدر باستخدام host أو dig -x. يفترض أن يُحل عنوان GPTBot الحقيقي إلى نطاق تابع لـ OpenAI؛ بعدها نفّذ استعلاماً أمامياً لذلك النطاق، وتأكد من أنه يعود إلى عنوان IP نفسه (forward-confirmed rDNS). لا تثق بالطلب إلا إذا تطابقت النتيجتان.
الخطوة 3: راقب ما يجلبه ورمز الحالة الذي يتلقاه
وصول الزاحف لا يعني أنه حصل فعلاً على محتواك. العامل الحاسم في إمكانية الاستشهاد بك داخل ChatGPT هو ما يتلقاه مع كل طلب. راقب الإشارات الأربع التالية.
- رمز الحالة: الوضع المثالي أن تكون جميع الاستجابات 200. كثرة استجابات 403 تعني غالباً أن Cloudflare أو WAF يصنّف GPTBot كزيارات مشبوهة ويحظره؛ أما 404 فتعني أن خريطة الموقع أو الروابط الداخلية تشير إلى عناوين URL غير صالحة؛ واستمرار أخطاء 5xx يعني أن الخادم يتعطل عند وصول الزاحف.
- الصفحات المشمولة: راجع قائمة المسارات التي يجلبها الزاحف، وتأكد من أنها تضم صفحات الأسعار والخطط والمقالات المتعمقة المرشحة للاستشهاد. إذا اقتصر الزحف على الصفحة الرئيسية وبعض المقالات القديمة، فسيظل محتواك الأساسي غير مرئي للذكاء الاصطناعي.
- الوصول إلى llms.txt وrobots.txt: يوضح السجل ما إذا كان الزاحف يطلب /llms.txt و/robots.txt. إذا أضفت llms.txt ولم يقرأه الزاحف قط، فهذا يعني أنه لا يعتمد هذه المجموعة من التعليمات حالياً؛ فلا تبالغ في تقدير أثرها.
- تكرار الزحف وحداثة المحتوى: قارن وقت نشر المقال أو تحديثه بمواعيد عودة GPTBot لجلبه من جديد. إذا طالت الفترة بين الزيارات، فسيتأخر دخول محتواك الجديد في نطاق فهم النموذج.
اقرأ السجلات أولاً، ثم تحدّث عن التحسين
قبل أن تستثمر وقتك في كتابة llms.txt أو إصلاح Schema أو إعادة صياغة المحتوى، خصص 10 دقائق للبحث في سجل الوصول باستخدام grep. تولّت Tenten ذات مرة حالة كان فيها llms.txt وSchema لدى العميل مُعدّين بصورة جيدة، لكن فحص السجل كشف أن WAF أعاد إلى GPTBot استجابة 403 في كل زيارة طوال نصف عام، فذهبت جميع التحسينات السابقة سدى. يخبرك السجل بوضوح إن كان GPTBot قد وصل، وما الذي جلبه، وأين جرى حظره. وهذه أرخص خطوة وأهمها في أي تحسين تقني ضمن GEO. وإذا أردت معرفة فجوات الظهور المختبئة في سجلاتك وما ينبغي إصلاحه أولاً، يمكنك حجز جلسة تشخيص GEO مدتها 30 دقيقة. سنراجع حالة الزحف مباشرة ونحدد لك المجالات الأكثر قابلية للتنفيذ.
