بتفتح تقرير الزيارات وتلاقي نص الطلبات جاية من بوتات. أول رد فعل طبيعي: اقفل الدنيا. وده بالظبط الخطأ اللي بيكلّف ناس كتير زيارات حقيقية وظهور في نتائج البحث.
المشكلة إن «اكتشاف زحف بوتات» و«وجود مشكلة بوتات» حاجتين مختلفتين تمامًا. وقبل ما تغيّر أي إعداد، محتاج تعرف البوتات بتعمل إيه بالظبط على موقعك.
الأرقام والتحليل في هذا المقال من بيانات Kinsta على أكثر من 5000 موقع ووردبريس، والمنهج الذي تشرحه ينطبق على أي استضافة.
أولًا: ما حجم المشكلة فعلًا؟
الحالات المتطرفة حقيقية وموثّقة. موقع PatronView سجّل 3.6 مليون طلب في يوم واحد من أكثر من 360 ألف عنوان IP، وانتهى صاحبه ببناء مجموعة قواعد صارمة على Cloudflare للسيطرة على الأمر. وعلى بنية Kinsta، ولّد زاحف واحد 3.75 مليون طلب على روابط «ووردبريس لتضيف له ميزة جديدة، مثل متجر أو نموذج تواصل أو تحسين للسيو، دون كتابة كود. اختر الإضافات الموثوقة المحدّثة، ولا…">الإضافة إلى السلة» في 24 ساعة — أي طلب كل 23 مللي ثانية تقريبًا.
لكن هذه الحالات لا تصف كل موقع.
في تحليل لأكثر من 5000 موقع ووردبريس، كان نصيب زواحف الذكاء الاصطناعي من الباندويدث (Bandwidth):
| الفئة | نصيب زواحف الذكاء الاصطناعي من الباندويدث |
|---|---|
| الموقع الوسيط | 1.57% |
| — | — |
| الشريحة التسعين | 17.8% |
| الشريحة التاسعة والتسعين | 90.3% |
| أكثر من 1000 موقع | صفر |
ومتوسط الطلبات اليومية لكل موقع تراوح بين 667 و928 طلبًا في أربع قياسات، في مقابل وسيط لا يتجاوز 33 إلى 67 طلبًا فقط. بعبارة أخرى: مجموعة صغيرة من المواقع المزحوفة بكثافة هي التي ترفع المتوسط.
فإذا قرأت أن البوتات تمثل أكثر من نصف زيارات الويب، أو رأيت صاحب موقع يشكو من 99% زيارات بوتات، فلا تستخدم رقمه لتقرر ما يحتاجه موقعك. ابدأ من بياناتك أنت.
الخطأ 1: اعتبار النسبة تشخيصًا
إذا كانت زواحف الذكاء الاصطناعي تمثل 20% من طلبات موقعك، فالرقم وحده لا يخبرك إن كانت هناك مشكلة.
نسبة كبيرة من الطلبات على مقالات مخزّنة في الكاش قد تضع ضغطًا ضئيلًا على التطبيق، في حين أن عددًا أقل بكثير يضرب صفحات البحث أو صفحات المنتجات المفلترة أو روابط السلة قد يخلق عملًا أكبر بمراحل.
قبل أن تتحرك، يجب أن تكون قادرًا على الإجابة عن أربعة أسئلة:
- كم من زيارات الذكاء الاصطناعي يصل إلى الموقع فعلًا؟
- أي الصفحات أو نقاط النهاية يطلبها؟
- أي الزواحف أو الأنظمة الآلية مسؤولة عنها؟
- هل يؤثر ذلك على الأداء أو الباندويدث أو خيوط PHP أو تجربة الزائر الحقيقي؟
الصيغة المختصرة: انظر إلى موضع الزيارات، ونمطها، وهوية مصدرها. موقع يستقبل زيارات ذكاء اصطناعي قليلة بسلوك طلب عادي قد لا يحتاج أي إجراء. وموقع يرى زحفًا مستمرًا على روابط ديناميكية مكلفة يستحق نظرة أقرب بكثير.
الخطأ 2: حجب كل البوتات لأن الزيارة آلية
مصطلح «بوت ذكاء اصطناعي» صار يغطي أنواعًا مختلفة من الزيارات، والفروق بينها تحدد ما تسمح به:
| الزاحف | الغرض المعلن | أثر حجبه |
|---|---|---|
GPTBot | محتوى قد يُستخدم في تحسين موديلات OpenAI | لا يؤثر على الظهور في بحث ChatGPT |
| — | — | — |
OAI-SearchBot | إظهار المواقع في بحث ChatGPT | يختفي محتواك من نتائج بحث ChatGPT |
ClaudeBot | محتوى قد يساهم في تدريب الموديلات | لا يؤثر على البحث |
Claude-SearchBot | فهرس البحث | يؤثر على الظهور في نتائج Claude |
Claude-User | جلب صفحة عند طلب مستخدم لها | المستخدم لا يستطيع فتح موقعك من داخل الأداة |
PerplexityBot | فهرس بحث Perplexity | اختفاء من نتائج Perplexity |
Perplexity-User | جلب صفحة ردًا على سؤال مستخدم | نفس الأثر السابق |
Google-Extended | تحكّم في استخدام المحتوى مع Gemini | لا يؤثر على الفهرسة أو الترتيب في بحث Google |
وضع كل هذه الأنظمة في سلة واحدة اسمها «AI» يعني التخلي عن معلومات كنت تستطيع استخدامها.
إذا كنت تفضّل ألّا تُصرف موارد موقعك على تدريب الموديلات، فبإمكانك تقييد زواحف التدريب وحدها مع إبقاء أنظمة البحث والجلب متاحة. وإذا كانت مشكلتك وكيلًا آليًا يضرب نقطة نهاية ديناميكية بتكرار، فتغيير سياستك تجاه زواحف التدريب لن يحلها من الأصل.
وهناك بُعد تجاري: في بحث استهلاكي لـ Kinsta، قال 44.7% من المشاركين إنهم يزورون موقع الشركة دائمًا أو في معظم الأحيان بعد توصية من أداة ذكاء اصطناعي. هذا لا يعني أن السماح للزواحف يولّد زيارات تلقائيًا، لكنه يعني أن الظهور في هذه الأدوات يستحق التفكير قبل قرار حجب شامل.
الخطأ 3: التعامل مع كل قفزة كأنها حادث أمني
البوتات تصنع مشاكل أمنية حقيقية: محاولات تخمين كلمات المرور، وهجمات الحرمان من الخدمة، وهجمات بيانات الدخول. لكن زاحفًا موثّقًا يرسل طلبات مشروعة كثيرة جدًا هو نوع آخر تمامًا من المشاكل.
يقول Daniel Pataki، المدير التقني في Kinsta، عن هذا الخلط تحديدًا:
«أخشى المبالغة في ردة الفعل في هذه الحالة أكثر مما أخشى التقصير في الاستجابة، لأنها ليست مشكلة أمنية.»
معظم الزيارات المزعجة التي تُرصد تأتي من أنظمة شرعية تزحف بطريقة غير كفؤة، لا من مهاجم يحاول اختراق الموقع.
الوضع يختلف إذا كان الموقع يتضرر فعلًا. لو كانت البوتات تستهلك موارد السيرفر وتبطّئ الصفحات وتمنع عملاءك الحقيقيين من الاستخدام، فتثبيت الموقع أولًا. احجب زيارات البوتات مؤقتًا، ثم حقّق بعد أن يستقر الوضع.
الخطأ هو تحويل إجراء الطوارئ هذا إلى سياسة دائمة دون أن تعرف ما حدث.
الخطأ 4: متابعة عدد الطلبات وتجاهل مقصدها
طلب لمقالة مخزّنة في الكاش وطلب لصفحة بحث في ووكومرس غير مخزّنة — كلاهما يُحسب طلبًا واحدًا، مع أن الثاني قد يحتاج عملًا أكبر بكثير على السيرفر.
الطلب الديناميكي يحتاج خيط PHP، واستعلامات قاعدة بيانات، وتوليد صفحة، وأحيانًا إدارة جلسة، قبل أن يعيد ووردبريس أي شيء. وأنشطة السلة وصفحة الدفع تضيف عملًا أكثر. الآن كرّر ذلك آلاف المرات.
وهنا الرقم الأهم في الموضوع كله: في ثلاث قياسات، ذهب ما بين 76.9% و90.5% من طلبات زواحف الذكاء الاصطناعي إلى محتوى ديناميكي، في مقابل 18.3% إلى 18.9% فقط من زيارات البشر.
هذا الفرق يخبرك عن الضغط المحتمل على بنيتك أكثر بكثير من عدد الطلبات الخام. ولهذا السبب قد يتصرف موقعان بنفس نسبة زيارات الذكاء الاصطناعي بشكل مختلف تمامًا: موقع محتوى تطلب الزواحف منه مقالات مخزّنة قد يستوعب حجمًا كبيرًا بلا مشكلة، ومتجر ووكومرس قد يشعر بالأثر أسرع بكثير لو كان عدد أقل من الطلبات يضرب البحث والفلاتر والسلة وصفحات الحساب بتكرار.
عند أي قفزة، تجاوز اسم الزاحف وانظر إلى المسار. رؤية GPTBot في أعلى التقرير معلومة مفيدة. ورؤية آلاف طلباته تذهب إلى /blog/ تقول شيئًا. ورؤيتها تذهب إلى نتائج البحث أو رابط ووكومرس بمعاملات تقول شيئًا مختلفًا تمامًا.
الخطأ 5: حجب الزاحف وترك مصيدة الزحف كما هي
أحيانًا البوت ليس إلا الشيء الذي كشف مشكلة قائمة أصلًا في بنية روابطك.
مواقع ووردبريس تولّد عددًا كبيرًا من الروابط: معاملات الاستعلام، وصفحات البحث، والأرشيفات المفلترة، وترقيم الصفحات، والتقويمات، ومتغيرات المنتجات، وأزرار الإضافة إلى السلة.
الإنسان يدرك أن رابطين مختلفين قليلًا يؤديان إلى نفس الصفحة تقريبًا. أما الزاحف فيرى روابط جديدة ليتبعها. وإذا كانت كل صفحة تولّد مجموعة روابط تبدو جديدة، يستمر الزاحف في المتابعة إلى ما لا نهاية. وهكذا تظهر أنماط تبدو أكثر شراسة مما قصده أي أحد. في حالة موثقة، كانت قاعدة واحدة مصممة لالتقاط نمط متكرر كافية لتصفية 550 مليون طلب في 30 يومًا.
حجب الزاحف قد يوقف الحمل الفوري، لكنه لا يزيل نمط الروابط الذي جعله يجد صفحات جديدة.
عندما يهيمن مسار معين على زيارات الزواحف، افحص المسار نفسه:
- هل يولّد ووردبريس أعدادًا كبيرة من تباديل المعاملات؟
- هل يستطيع الزاحف التنقل في روابط التقويم أو ترقيم الصفحات بلا نهاية؟
- هل تكشف صفحات البحث والفلترة آلاف الصيغ من الروابط؟
- هل روابط الإجراءات مثل الإضافة إلى السلة قابلة للزحف بينما لا حاجة لذلك؟
- هل كل رابط يُولَّد يحتاج فعلًا أن يوجد وأن يكون قابلًا للاكتشاف؟
ملاحظة تهم المواقع العربية تحديدًا: لو كنت تستخدم روابط دائمة (Permalinks) عربية، فكل رابط يظهر في السجلات مشفّرًا بترميز النسبة المئوية (%D8%A7…)، وهذا يجعل قراءة السجلات وبناء قواعد الحجب أصعب بكثير — والرابط نفسه أطول، فتضخم أنماط المعاملات يكون أسرع في الظهور. وإذا كنت تبني الفلترة بـ JetSmartFilters أو بفلاتر ووكومرس، تأكد من أن روابط الفلترة تحمل noindex ومحجوبة في robots.txt قبل أن تلوم أي زاحف.
في القالب كاملًا والنماذج والنوافذ المنبثقة.">Elementor و ومنشئ الاستعلامات مع Elementor.">JetEngine: الـ Listing Grid المبنية على استعلام بمعاملات في الرابط يمكن أن تولّد عددًا هائلًا من التباديل القابلة للزحف. راجع الـ Query Builder عندك وحدّد أي المعاملات تحتاج أن تكون في الرابط فعلًا، وأيها يمكن أن يعمل عبر طلب AJAX بدون رابط مستقل.
هذا مهم بشكل خاص للوكالات: إذا كانت عدة مواقع لعملائك تستخدم نفس الإضافة أو نفس إعداد ووكومرس أو نفس نمط الروابط، فزاحف واحد نشط سيكشف نفس المشكلة على أكثر من موقع. إصلاح السلوك أنفع من صيانة قائمة أسماء بوتات لا تتوقف عن الطول.
الخطأ 6: افتراض أن robots.txt أوقف الزيارات
تعديل robots.txt قد يكون الاستجابة الصحيحة عندما تريد إبلاغ زاحف محترم بعدم الوصول إلى جزء من موقعك أو إليه كله. لكن عليك أن تراجع الزيارات بعد التعديل.
الملف يعتمد على احترام الزاحف للتعليمة، وهو لا يمنع الطلب فيزيائيًا من الوصول إلى موقعك. robots.txt يوصّل تفضيلات الزحف، وملف llms.txt يقدّم فهرسًا منظّمًا للمحتوى للأدوات التي تختار قراءته. أما التنفيذ فيحدث في مكان آخر.
وهذه النقطة تهم تحديدًا بعد اكتشاف مشكلة أداء، لأن تعديل ملف قد يمنحك إحساسًا زائفًا بأن الأمر انتهى.
راجع سجلاتك أو تحليلات البوتات. إذا انخفضت طلبات الزاحف بعد التعديل، فلديك دليل على أنه عمل. وإذا استمرت الزيارات، أو كنت تتعامل مع نظام آلي لا يتبع التعليمة، فأنت تحتاج أداة تنفيذ فعلية.
ونفس الأمر ينطبق عندما تكون مشكلتك معدل الطلبات لا الوصول نفسه: قد يكون الزاحف مسموحًا له بقراءة محتواك، ويطلبه بمعدل لا يستطيع موقعك خدمته بارتياح.
الخطأ 7: نسخ قواعد جدار حماية موقع آخر
مثال PatronView مفيد لأن استجابة الموقع بُنيت على بياناته الخاصة. جمهوره في أمريكا الشمالية بأغلبية ساحقة، فصاحبه يتحدّى الزيارات القادمة من قارات أخرى. وقد راجع بيانات زواره الحقيقيين قبل أن يتحدى مستخدمي المتصفحات القديمة، ويتابع كم من المتحدَّين يجتازون التحدي فعلًا: في فترة واحدة، لم تُحَل سوى 0.24% من أكثر من 100 ألف تحدٍّ.
هذه الأرقام تجعل القواعد مبرَّرة لذلك الموقع. وتطبيق نفس الإعداد على متجر دولي قد ينتهي بتحدي عملاء حقيقيين.
وهذه نقطة حرجة لموقع عربي: جمهورك موزّع بين مصر والخليج والمغرب العربي، وجزء كبير من قرّائك عرب مقيمون في أوروبا وأمريكا وكندا. قاعدة تحجب أو تتحدى قارة كاملة ستقطع شريحة حقيقية من جمهورك ولن تظهر لك في تقارير الحجب كخسارة. لو اضطررت لقواعد جغرافية، ابدأ بوضع «التحدي» لا «الحجب»، وراجع نسبة اجتياز التحدي أسبوعيًا.
الخطر نفسه يظهر عندما تتكدس عدة أدوات حماية لأن كل واحدة تبدو مفيدة بمفردها. موقع ووردبريس واحد قد يكون عليه حماية بوتات من الاستضافة، وقواعد Cloudflare، وإضافة أمان، وتحديد معدل، وحجب دول، وقواعد WAF مخصصة — كلها تتخذ قرارات عن نفس الطلب. وتشخيص حجب خاطئ يصبح أصعب بكثير عندما لا تعرف أي طبقة اتخذت القرار.
والمستويات المرتفعة من الحماية قد تؤثر أيضًا على الأتمتة المشروعة: الـ API، وأدوات المراقبة، وWebhooks، وتكاملات ووردبريس — بما فيها طلبات wp-cron وبوابات الدفع المحلية التي تستدعي موقعك لتأكيد العملية. لو حجبت هذه من غير قصد، ستظهر لك كأوردرات معلّقة لا كمشكلة حجب.
إن كنت تدير وكالة، فالعملية الموحّدة أنفع من مجموعة القواعد الموحّدة. يمكنك استخدام نفس الخطوات على 20 موقع عميل: تحديد نوع الزيارات، وفحص مساراتها، ومراجعة الأداء، واختيار إجراء، واختباره، ومتابعة النتيجة.
ماذا تفعل عند اكتشاف زحف بوتات؟
ابدأ من الواقع على موقعك. إذا كانت زيارات البوتات تؤثر على زائر حقيقي، فأمّن الموقع أولًا، ثم افحص الحجم والمسارات والأنظمة المسؤولة.
بعد ذلك اختر أصغر تغيير يحل المشكلة: تعديل robots.txt، أو حجب زاحف أو تحدّيه، أو إصلاح نمط روابط قابل للزحف، أو ألّا تفعل شيئًا إذا كانت الزيارات لا تسبب ضررًا. الخيار الأخير صحيح تمامًا، وهو الأكثر إغفالًا.
الخلاصة
قبل ما تقفل أي حاجة، افتح تحليلات الاستضافة أو Cloudflare عندك وبص على تلات أرقام: نسبة زيارات البوتات، المسارات اللي بتضربها، وهل الأداء اتأثر ولا لأ.
لو الطلبات كلها على مقالات مخزّنة في الكاش، سيبها. ولو بتضرب صفحات البحث والفلترة، المشكلة في الروابط بتاعتك مش في البوت — وده اللي محتاج إصلاح.
مرجع المقال (بالإنجليزية): The 7 biggest mistakes site owners make after discovering AI bot traffic
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.
اقرأ أيضًا
الأسئلة الشائعة
كم تمثل بوتات الذكاء الاصطناعي من زيارات موقعي عادةً؟
في تحليل Kinsta لأكثر من 5000 موقع ووردبريس، كان نصيب زواحف الذكاء الاصطناعي من الباندويدث 1.57% في الموقع الوسيط، و17.8% عند الشريحة التسعين، و90.3% عند الشريحة التاسعة والتسعين. وأكثر من 1000 موقع لم يسجّل أي استهلاك منها. أي أن الأرقام الكبيرة التي تقرأها تصف مواقع قليلة، لا موقعك بالضرورة.
هل أحجب كل بوتات الذكاء الاصطناعي؟
ليست فئة واحدة. بعض الزواحف تجمع المحتوى لتدريب الموديلات، وبعضها يبني فهرس بحث، وبعضها يجلب صفحتك لحظة أن يسأل مستخدم عنها. حجب الجميع يعني أيضًا اختفاء محتواك من نتائج البحث داخل أدوات الذكاء الاصطناعي.
هل يكفي تعديل ملف robots.txt لإيقاف الزحف؟
لا. ملف robots.txt يعبّر عن تفضيلك ويعتمد على احترام الزاحف له، وهو لا يمنع الطلب فيزيائيًا من الوصول إلى السيرفر. بعد أي تعديل راجع سجلات السيرفر: إذا انخفضت الطلبات فقد نجح، وإذا استمرت فأنت تحتاج أداة تنفيذ فعلية مثل قاعدة على Cloudflare.
ما أخطر أنواع الزحف على موقع ووكومرس؟
الطلبات التي تصل إلى مسارات غير مخزّنة في الكاش: صفحات البحث، وروابط الفلترة بالمعاملات (Query Parameters)، وصفحات الحساب، وروابط الإضافة إلى السلة. في دراسة Kinsta كان ما بين 76.9% و90.5% من طلبات زواحف الذكاء الاصطناعي يذهب إلى محتوى ديناميكي، مقابل نحو 18% فقط من طلبات البشر.
هل زحف البوتات مشكلة أمنية؟
ليس بالضرورة. الهجمات وتجربة كلمات المرور والحرمان من الخدمة مشاكل أمنية. أما زاحف موثّق يرسل طلبات مشروعة بكثافة زائدة فهو مشكلة أداء وأحمال. الخلط بين الاثنين يؤدي إلى ردة فعل مبالغ فيها تحجب زيارات حقيقية.
