كيف تجهّز موقعك المستضاف ذاتيًا لوكلاء الذكاء الاصطناعي

في نقاش على Hacker News حول حركة زواحف الذكاء الاصطناعي، وصف أحد مسؤولي الاستضافة الحمل من جانب المشغّل: «نحو 6 روبوتات ذكاء اصطناعي عدوانية إلى حد كبير» تعلق دوريًا في صفحات متغيّرات المنتجات أو التصنيفات وتبدأ بطرقها بمعدل طلب واحد تقريبًا في الثانية، على موقع «قد يستغرق فيه تحميل كل صفحة ثانية كاملة ذهابًا وإيابًا (معظمها داخل MySQL)». والأثر التراكمي، في التعليق نفسه: «أقرب إلى أن يتعرض الموقع لتأثير Slashdot كل يوم».

تجهيز موقعك لوكلاء الذكاء الاصطناعي هو مسألة سعة قبل أي شيء آخر، لذا فإن معظم العمل هنا هو ضبط للخادم وقليل جدًا منه استراتيجية محتوى. الميزة المفيدة في هذه الحركة أن أغلبها ليس مجهول الهوية: الشركات التي تولّدها تنشر أسماء زواحفها، وتوثّق الغرض من كل واحدة منها، وتخبرك كيف توقفها. وفيما يلي ما ينبغي ضبطه، وما يفرضه كل آلية عمليًا، والخطوتان اللتان كنت سأتخطاهما: نشر ملف llms.txt، وإضافة ترميز schema من أجل الذكاء الاصطناعي.

الخلاصة السريعة

• تنقسم حركة الذكاء الاصطناعي عادةً إلى تدريب، وفهرسة للبحث بالذكاء الاصطناعي، وطلبات يبدأها المستخدم. تتيح OpenAI وAnthropic رموزًا منفصلة لهذه الأغراض، فيمكنك التحكم بها بشكل مستقل؛ بينما تجمع بعض الزواحف متعددة الأغراض أكثر من دور تحت هوية واحدة.
• توثّق OpenAI وAnthropic وPerplexity وCommon Crawl ضوابط robots.txt لزواحفها التلقائية. أما جالبات الصفحات التي يبدأها المستخدم فهي الاستثناء: تطبّق Anthropic ملف robots.txt على Claude-User أيضًا، وتقول OpenAI إن القواعد قد لا تنطبق على ChatGPT-User، بينما يتجاهلها Perplexity-User عمومًا.
• ملف robots.txt آلية موافقة، لا ضابط وصول. فـ RFC 9309 لا يمنحه أي قدرة إنفاذ خاصة به؛ والروبوتات الملتزمة قد تخفّف حملك باحترامه، لكنه لا يستطيع كبح الحركة غير الملتزمة ولا إيقافها.
• عبر 137,210 نطاقات ضمن قاعدة عملاء التحليلات لدى Ahrefs، لم تتلقَّ 97% من ملفات llms.txt المنشورة أي طلب في مايو 2026. انشر واحدًا إن أردت، لكن لا تبنِ حوله أدوات.
• أبقِ البيانات المنظّمة حيث تدعم ميزات البحث التقليدية، لكن توثيق Google يقول إن ميزاته المدعومة بالذكاء الاصطناعي لا تتطلب أي مخطط خاص ولا ملفًا نصيًا للذكاء الاصطناعي.
• أظهِر المحتوى الحرج من جانب الخادم إن أردت أن تقرأه OpenAI أو ClaudeBot أو PerplexityBot أو CCBot. وجدت Vercel أن هذه الزواحف لا تنفّذ JavaScript؛ والاستثناءان هما Gemini عبر Googlebot وAppleBot.
• ما وراء قواعد robots.txt التعاونية، يقع الإنفاذ الفعلي عند الوكيل العكسي، أو في جدار حماية تطبيقات ويب تشغّله بنفسك، أو خلف تحدٍّ قائم على إثبات العمل، بهذا الترتيب من حيث التكلفة.

ما لا يغطّيه هذا المقال

الحديث هنا عن موقع يزوره الوكلاء، لا عن موقع يجري معهم معاملات. وقد تُركت أربعة موضوعات مجاورة جانبًا.

• التجارة القائمة على الوكلاء ومسارات إتمام الشراء، وهي مشكلة مختلفة تخصّ نوعًا آخر من المواقع.
• الجدل القانوني وحقوق النشر حول بيانات التدريب، وهو قرار عمل لا إعداد خادم.
• شرح تفصيلي لتطبيق WebMCP، إذ لا يزال المعيار في مرحلة التجربة الأصلية (origin trial).
• الإعدادات الخاصة بكل شبكة توصيل محتوى، بخلاف قسم Cloudflare الوحيد أدناه.

أي زواحف الذكاء الاصطناعي تطرق موقعك

يجمع GPTBot وClaudeBot محتوى قد يُستخدم في تدريب النماذج. ويدعم OAI-SearchBot وClaude-SearchBot البحث والاسترجاع بالذكاء الاصطناعي. أما ChatGPT-User وClaude-User فيجلبان الصفحات استجابةً لإجراءات المستخدم. هذه المهام منفصلة لدى بعض المزوّدين، لكن ليس كل زاحف على الويب ينطبق عليه غرض واحد بدقة.

صورة الالتزام أدق مما يوحي به الاختصار الشائع. توثيق Anthropic الخاص بالزواحف يقول إن ClaudeBot وClaude-User وClaude-SearchBot تحترم ملف robots.txt. توثيق OpenAI الخاص بالروبوتات يقول إن زواحفها التلقائية تستخدم ضوابط مستقلة، لكن قواعد robots.txt قد لا تنطبق على ChatGPT-User لأن تلك الطلبات يبدأها شخص. توثيق Perplexity الخاص بالزواحف يميّز تمييزًا مشابهًا: يتّبع PerplexityBot ضوابط مشرفي المواقع، بينما يتجاهل Perplexity-User عمومًا ملف robots.txt. لذا فإن الادعاء العام بأن روبوتات الذكاء الاصطناعي تتجاهل robots.txt يخلط بين زواحف موثّقة تحترم الملف، وجالبات يبدأها المستخدم يتفاوت سلوكها حسب المزوّد، وكاشطات لا تعرّف عن نفسها إطلاقًا.

الجدول أدناه محدَّث حتى لحظة الكتابة. تظهر رموز جديدة أسرع مما يمكن لأي مقال أن يتابعه، فتعامل معه كخريطة بداية ذات عمر قصير.

كتابة قواعد robots.txt لزواحف الذكاء الاصطناعي

RFC 9309 يقول إن القواعد في robots.txt ليست شكلًا من أشكال تصريح الوصول. فقد وحّدت IETF بناء الجملة والتحليل والتخزين المؤقت في سبتمبر 2022؛ لكنها لم تحوّل الملف إلى آلية إنفاذ. التفاصيل التي تؤثر عمليًا تقع تحت بناء الجملة: يجب أن يكون الملف مرمّزًا بـ UTF-8، ويجب أن تعالج المحلّلات 500 كيبيبايت على الأقل، وعند تعارض التوجيهات يفوز أكثر مطابقات المسار تحديدًا. أما موضع القاعدة داخل الملف فلا أثر له.

ملف robots.txt الخاص بروبوتات الذكاء الاصطناعي يستخدم الملف نفسه وبناء الجملة نفسه الموجود لديك أصلًا؛ ما يتغيّر هو قائمة الرموز. نظّم القواعد حسب الغرض، وستدوم أطول من قائمة المزوّدين. وإن كان اعتراضك على التدريب، فاحجب رموز التدريب واترك المفهرسات وشأنها:

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

إن أردت إرسال إشارة انسحاب على مستوى الموقع لكل رمز مذكور في الجدول، فاجمعها تحت قاعدة واحدة. لا داعي لتكرار Disallow إحدى عشرة مرة:

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

لا يزال ذلك ليس حجبًا شاملًا. تطبّق Anthropic ملف robots.txt على Claude-User، لكن OpenAI تقول إن القواعد قد لا تنطبق على ChatGPT-User، وPerplexity-User يتجاهلها عمومًا. وإذا كان لا بدّ من إيقاف تلك الطلبات التي يبدأها المستخدم لا مجرد تثبيطها، فنفّذ ذلك القرار عند الوكيل أو جدار حماية التطبيقات.

Google-Extended هو الرمز الأكثر تعرضًا لسوء الفهم، والتمييز مهم إذا كانت حركة البحث هي ما يدفع فواتيرك. توثيق Google الخاص بالزواحف يصفه بأنه رمز منتج مستقل يتحكم في ما إذا كان المحتوى المزحوف يمكن استخدامه لتدريب Gemini وتأسيس إجاباته خارج البحث، ويقول إنه لا يؤثر في إدراج الموقع أو ترتيبه في بحث Google. وحجبه لا يمسّ سلوك Googlebot في البحث.

تحديث قائمة الرموز يدويًا ليس استخدامًا جيدًا لبعد ظهيرة أحد. مستودع ai.robots.txt الذي يصونه المجتمع فيتتبّع وكلاء مستخدمي الذكاء الاصطناعي ويولّد إعدادات لـ robots.txt وnginx وCaddy وHAProxy وLighttpd وApache. ويستطيع مشغّلو Apache وضع الكتلة المولَّدة إلى جانب بقية قواعد .htaccess على مستوى الدليل.

نصيحة احترافية: لا تثق بسلسلة user-agent. فهي ترويسة، والترويسات يسهل تزويرها بلا كلفة. توثيق CCBot من Common Crawl يحذّر من أن هناك زواحف تنتحل هوية CCBot. وبالنسبة إلى IPv4، تحقّق عبر DNS عكسي مؤكَّد أماميًا ضمن *.crawl.commoncrawl.org؛ أما لعناوين IPv6 فاستخدم نطاقات العناوين التي تنشرها Common Crawl، لأن الـ DNS العكسي غير مدعوم هناك حاليًا. كما تنشر صفحات المزوّدين المذكورة أعلاه نطاقات العناوين الحالية لبقية الزواحف المسمّاة. وهذا مسار تحقق موثّق لدى هؤلاء المزوّدين، لا خاصية في زواحف الذكاء الاصطناعي عمومًا.

هل يفعل llms.txt أي شيء؟

بحسب الأدلة الحالية، لا شيء يُذكر تقريبًا. ملف llms.txt هو ملف نصي مقترح في جذر موقعك يقدّم لنماذج اللغة ملخصًا منسّقًا لمحتواك. نشره رخيص، لكن الأدلة الحالية لا تعطيك سببًا يُذكر للاستثمار فيه، وتوثيق Google يقول إنك لست بحاجة إليه لميزات البحث المدعوم بالذكاء الاصطناعي.

الصيغة بسيطة إلى أقصى حد. مقترح llms.txt يعود إلى سبتمبر 2024، ويوجد في /llms.txt، ويجعل عنوان H1 يحمل اسم الموقع أو المشروع القسم الإلزامي الوحيد.

الحكم يأتي من القياسات. دراسة Ahrefs التي شملت 137,210 نطاقات وجدت أن 28% من النطاقات المقيسة تنشر ملف llms.txt، وأن 97% من تلك الملفات لم تتلقَّ أي طلب في مايو 2026. ومن الطلبات التي وصلت فعلًا، جاء 19.5% من أدوات ذكاء اصطناعي معروفة بالاسم. كما تحذّر Ahrefs من أن جلب الملف لا يثبت أنه استُخدم فعليًا.

قراءتي لتلك البيانات أن llms.txt رهان على عُرف لم تعتمده على نطاق واسع الأنظمة التي كُتب من أجلها. انشره إن كنت تحب جذورًا مرتبة. لكن لا تبنِ حوله خط إنتاج، ولا تدعه يصبح خطوة معطِّلة في نشرك، واعتبر كل من يبيعه لك كرافعة للترتيب أو للاستشهاد متقدمًا على الأدلة بمسافة لا بأس بها.

الفكرة الرئيسية: في دراسة Ahrefs، لم تتلقَّ 97% من ملفات llms.txt المنشورة أي طلب على الإطلاق في مايو 2026.

جعل صفحاتك قابلة للقراءة آليًا

قياس Vercel للزواحف وجد أن زواحف OpenAI وClaudeBot وPerplexityBot وMeta-ExternalAgent وBytespider وCCBot لا تنفّذ JavaScript، بينما ينفّذه Gemini عبر Googlebot وكذلك AppleBot. وبالنسبة إلى الزواحف التي لا تنفّذه، فإن المحتوى الذي لا يظهر إلا بعد الترطيب من جانب العميل يكون غير مرئي، لذا أظهِر كل ما هو حرج من جانب الخادم. أما الترميز فمسألة أسهل، وإرشادات Google بشأنه صريحة على نحو غير معتاد:

«لست بحاجة إلى إنشاء ملفات جديدة قابلة للقراءة آليًا، أو ملفات نصية للذكاء الاصطناعي، أو ترميز، كي تظهر في هذه الميزات. كما لا توجد بيانات منظّمة خاصة من schema.org يلزمك إضافتها.»

إرشادات Google Search Central بشأن الذكاء الاصطناعي

أما زيادة الظهور بنسبة 40% التي يُستشهد بها أحيانًا لدعم ترميز FAQ فمصدرها ورقة GEO البحثية ، المقبولة في مؤتمر KDD 2024. تفيد الورقة بمكاسب تصل إلى 40%، لكن التدخلات التي اختبرتها تركّز على تغييرات في المحتوى مثل الاستشهادات والاقتباسات والإحصاءات والمصطلحات التقنية وسلاسة الصياغة، لا على FAQPage ولا على أي ترميز آخر من Schema.org. الرقم صحيح؛ أما ربطه بترميز schema فليس كذلك.

أبقِ البيانات المنظّمة حيث تدعم ميزة بحث تقليدية وتطابق الصفحة المرئية. تقول Google إن الأهلية لميزاتها المدعومة بالذكاء الاصطناعي تمرّ عبر فهرسة البحث الاعتيادية، دون شرط ترميز منفصل. غير أنه لم يثبت أنها تحرّك الاستشهاد من قِبل الذكاء الاصطناعي.

حين لا يكفي robots.txt: تحديد المعدل وجدار حماية التطبيقات على الخادم

تعمل التوجيهات مع الروبوتات التي اختارت الالتزام. وفي النقاش نفسه على Hacker Newsوصف عدة مشغّلين الحركة التي لا تلتزم: زواحف توزّع طلباتها على مجموعات ضخمة من كتل عناوين IP وتبدّل وكلاء المستخدم لتبدو كزوار عاديين، وهو ما يُفشل الحدود الساذجة لكل عنوان IP ومطابقة وكيل المستخدم على حد سواء. تعامل مع ذلك بوصفه إفادات من المجتمع؛ فلم ينشر أحد في النقاش قياسات. لكنه يصف بدقة الفئة التي لم يُبنَ robots.txt يومًا للوصول إليها.

قبل أن تصعد ذلك السلّم، ثمة خطوة أرخص متاحة للحركة التي ما زالت متعاونة: أبطئها:

User-agent: ClaudeBot
Crawl-delay: 1

نصيحة احترافية: قلّل السرعة قبل أن تحجب. توثيق Anthropic يدعم Crawl-delay لـ ClaudeBot ، فيمكنك إبطاء زاحف ثقيل لكنه مهذّب والإبقاء عليه. وتقول الصفحة نفسها إن حجب عناوين IP ليس آلية انسحاب دائمة. وكلتا النقطتين تخصّان Anthropic تحديدًا؛ Crawl-delay ليس توجيهًا عالميًا، لذا راجع توثيق كل مزوّد أولًا.

وكل ما بعد ذلك هو إنفاذ تديره بنفسك، على ثلاث درجات تتصاعد كلفةً وفعاليةً. كل درجة تشتري شيئًا وتتنازل عن شيء.

الدرجة 1: توجيهات الوكيل العكسي وتحديد المعدل

يبدأ تحديد معدل زواحف الذكاء الاصطناعي عند الوكيل العكسي، أول عنصر في منظومتك يرى الطلب ويستطيع إبطاءه قبل أن يقوم التطبيق أو قاعدة البيانات بأي عمل. توثيق NGINX الخاص بتحديد المعدل ينصّ على أن الطلبات ذات المفتاح الفارغ لا تُحتسب، لذا فإن map يمكنه منح مفتاح تحديد المعدل لرموز الزواحف التي تريد كبحها فقط، مع ترك الطلبات غير المطابقة خارج limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

الزوج الذي عليك ضبطه هو burst=10 nodelay؛ فالطلبات التي تتجاوز المعدل المتوسط يمكنها استهلاك الدفعة فورًا، أما ما يتجاوزها فيتلقّى 503 افتراضيًا. وإن ضبطته بإحكام مفرط فستطرد زاحفًا مشروعًا في منتصف زحفه، وهي مشكلة تشخيصها أبطأ من انقطاع الخدمة. ويعبّر Caddy عن الفكرتين نفسيهما عبر مطابِق ومعالج؛ وإن كنت تختار بينهما، فإن ملفات الإعداد جنبًا إلى جنب أنفع من رقم إنتاجية اصطناعي.

قصور هذه الدرجة أن المسار البطيء ما زال يعتمد على وكيل المستخدم المعلن. فالكاشط الذي يرتدي وكيل مستخدم Chrome يتجاوز هذا المفتاح المخصص للزواحف تمامًا؛ والإمساك بتلك الحركة يتطلب تحديدًا أوسع للمعدل قائمًا على سلوك عناوين IP والمسارات، أو درجة جدار حماية التطبيقات أدناه.

الدرجة 2: جدار حماية تطبيقات ويب تشغّله بنفسك

ينقل جدار حماية التطبيقات القرار من ترويسة واحدة إلى مجموعة قواعد تقرأ أنماط الطلبات والمسارات والمعدلات معًا، وهو ما تحتاجه حين تكفّ الحركة عن التعريف بنفسها. وتشغيله على جهازك يُبقي القواعد والسجلات على قرصك، حيث يمكنك تفحّصها بـ grep عند الثالثة فجرًا. BunkerWeb أحد هذه المشاريع، SafeLine هو الآخر، وكلاهما يعمل على خادم افتراضي متى استوفى المضيف متطلبات المشروع من حيث المعمارية والموارد؛ ونحن نوفّر نسختين بنقرة واحدة من كليهما لنوفّر عليك الإعداد، وإن لم تكن التعبئة هي الجزء المثير للاهتمام.

وهذه أيضًا كلفة هذه الدرجة. فالقواعد تحتاج صيانة، والقاعدة المضبوطة بما يكفي لالتقاط كاشط عنيد ستلتقط في النهاية إنسانًا. وأوضاع Monitor وBalanced وStrict في SafeLine تجعل هذه المفاضلة صريحة: ابدأ بمراقبة الحركة مدة كافية لاكتشاف الإيجابيات الكاذبة قبل أن تدع جدار الحماية يعيد استجابات 403 تلقائيًا.

الدرجة 3: تحديات إثبات العمل

يتجاوز Anubis مشكلة تحديد الهوية تمامًا. فبالنسبة إلى الحركة التي تختار تحدّيها، يجعل الطلب يدفع كلفة حسابية صغيرة قبل أن يخدمه الخادم الأصلي. أما نظام السياسات فيه فيمكنه أيضًا السماح بالطلبات أو رفضها أو تحدّيها وفق قواعد مطابقة. ويصف ملف README الخاص بالمشروع ملف README الخاص بالمشروع الأداة بأنها Web AI Firewall Utility مبنية على التحديات لحماية موارد المنبع من روبوتات الكشط. وهي تعمل دون أن تشترط أن يعرّف كل روبوت عن نفسه بشكل صحيح.

يصف المشروع نفسه هذا النهج بأنه ردّ نووي، والتحفّظ في محله. فالضريبة تقع على أي حركة تتحدّاها سياستك، وقد تشمل بشرًا على أجهزة بطيئة أو زواحف مشروعة إن كانت القواعد فضفاضة. احتفظ بهذه الدرجة احتياطيًا للحركة العدائية فعلًا. فالزاحف المتحمّس عادةً مشكلة تحديد معدل، وأنت تملك تحديد المعدل أصلًا.

تحديد الحجم استعدادًا للاندفاع

غالبًا ما يصل حمل الزواحف على شكل اندفاعات، لكن كونه ثقيلًا على المعالج أو قاعدة البيانات أو الإدخال/الإخراج يتوقف على التطبيق وعلى الروابط التي تُزحف. في مثال WordPress أعلاه، عزا المشغّل معظم الثانية التي يستغرقها تحميل الصفحة إلى MySQL، فكانت تلك الحادثة تحديدًا اختناقًا في قاعدة البيانات جاء متنكرًا في هيئة مشكلة حركة مرور.

وهذا يحوّل تحديد الحجم إلى مسألة تخصيص، ومسألة مزعجة: فأنت تدفع ثمن الهامش باستمرار، ولا يبرّر وجوده إلا أثناء اندفاع لا تتحكم به. خصّص للاندفاع رغم ذلك. وإذا كان BunkerWeb يتشارك المضيف مع التطبيق وقاعدة البيانات، فلا تعتبر 8 غيغابايت توصية للمنظومة كاملة. دليل البدء السريع لـ BunkerWeb بـ 2 vCPU و8 غيغابايت من الذاكرة للاختبار أو النشر بعدد قليل جدًا من الخدمات، وبما لا يقل عن 4 vCPU مع 16 غيغابايت لبيئات الإنتاج التي تحمي خدمات كثيرة. أضف فوق ذلك ذروة استهلاك التطبيق للمعالج، وذاكرة قاعدة البيانات، وهامش الإدخال/الإخراج.

تفيد النوى ذات التردد الأعلى حين تكون معالجة الطلبات أو تنفيذ الاستعلامات مقيدة بالمعالج؛ ويفيد ازدياد عدد النوى حين تحتاج إلى مزيد من العمل المتزامن. حدّد الحجم انطلاقًا من ذروة التزامن، وزمن الاستجابة عند p95، واستهلاك المعالج وانتظار الإدخال/الإخراج في قاعدة البيانات، ومعدل إخفاق الذاكرة المؤقتة، لا من حركة الزواحف وحدها.

تشغيل هذه الطبقة بنفسك يتطلب أمرين من الجهاز الذي تحتها: صلاحية الجذر، لأن كل آلية أعلاه ملف إعداد تحرّره وخدمة تعيد تشغيلها، وهامش كافٍ حتى لا يُسقط اندفاعٌ الموقعَ بينما تؤدي القواعد عملها. وإذا كنت تحدّد حجم خادم أو تنقل واحدًا لهذا الغرض، فإن Linux VPS يمنحك صلاحية الجذر التي تتطلبها هذه المنظومة، ويتيح لك اختبار إعداد الوكيل وجدار الحماية قبل أن تلتزم بحجم طويل الأمد.

ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.

عرض باقات Linux

الإعدادات الافتراضية الجديدة لدى Cloudflare لحركة الذكاء الاصطناعي

قسّمت Cloudflare حركة الذكاء الاصطناعي إلى فئات Search وAgent وTraining في إعلانها الصادر في يوليو 2026 بشأن حركة الذكاء الاصطناعي. واعتبارًا من 15 سبتمبر 2026، ستُحجب فئتا Training وAgent افتراضيًا للنطاقات الجديدة المنضمة إلى Cloudflare على الصفحات التي تعرض إعلانات، بينما تبقى Search مسموحة. ويمكن للعملاء الحاليين تغيير الإعداد قبل ذلك، والضوابط متاحة في جميع الباقات.

الجزء الجدير بالاقتباس هو التعقيد الذي تسمّيه Cloudflare في إعلانها نفسه. ففي تصنيفها، يجمع كلٌّ من Googlebot وApplebot وBingbot بين عمل البحث وعمل التدريب، ولذلك فإن العميل الذي يحجب فئة Training يحجب تلك الزواحف أيضًا، بما في ذلك سلوك البحث الذي أراد الاحتفاظ به. وهذا هو الفخ نفسه الكامن في أي ضابط على مستوى الفئات يعامل زاحفًا متعدد الأغراض كما لو كانت له مهمة واحدة.

إذا لم يكن موقعك خلف Cloudflare، فلا شيء من هذا رافعة بيدك. لكن اعلم أنه قادم، لأنه سيغيّر أنماط الحركة في سبتمبر؛ وتبقى أدواتك هي رموز robots.txt وطبقة الوكيل المذكورة أعلاه.

WebMCP: يستحق المتابعة، لا البناء عليه

WebMCP هو النظير من جانب المتصفح لـ Model Context Protocol، وهو العُرف الذي تستخدمه الوكلاء لاستدعاء أدوات منظّمة بدل التخمين. أما إعلان Chrome عن التجربة الأصلية لـ WebMCP فيصوغ الهدف مباشرةً: بدل أن يخمّن الوكيل وظيفة زر أو حقل نموذج، يمكن للموقع أن يعرض دوالّ منظّمة وعناصر تحكم موصوفة يستطيع الوكيل استدعاءها مباشرة.

إنها أول محاولة جادّة لمنح الوكلاء ما يفعلونه في موقعك أبعد من مجرد قراءته، وهو ما يجعلها أكثر ما في هذا المقال إثارة للاهتمام. وهي في الوقت نفسه تجريبية وغير مكتملة: تجربة أصلية في Chrome 149 فُتحت في يونيو 2026. راقب المواصفة. لا تشحن بعدُ اعتمادًا إنتاجيًا حولها، وأبقها خارج خطة السعة لديك.

الأسئلة الشائعة

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn