--- title: 'Cloudflare تحظر عملاء AI: حل بديل مُجرب (2026)' description: تقوم Cloudflare الآن بحظر عملاء AI بشكل افتراضي على الصفحات التي تعتمد على تحقيق الربح من الإعلانات. إليكم نمط Python مُختبر لأدوات جلب الويب للكشف عن ذلك والفشل بشكل لائق، بدلاً من محاولة تزييف الهوية. url: https://nerdleveltech.com/ar/cloudflare-blocks-ai-agents-fallback-pattern language: ar date: '2026-09-16' category: ai-ml tags: - cloudflare - ai agents - web fetch tool - bot management - ai crawl control - robots.txt markdown_url: https://nerdleveltech.com/ar/cloudflare-blocks-ai-agents-fallback-pattern.md attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/ar/cloudflare-blocks-ai-agents-fallback-pattern' terms: https://nerdleveltech.com/llms.txt --- # Cloudflare تحظر عملاء AI: حل بديل مُجرب (2026) تتعامل Cloudflare الآن مع وكلاء الذكاء الاصطناعي (AI agents) كفئة منفصلة يمكن حظرها، بعيداً عن زواحف البحث والتدريب. ومنذ 15 سبتمبر 2026، أصبحت المواقع الجديدة التي تعتمد على الربح من الإعلانات تحظر بشكل افتراضي سلوك الـ **Agent** هذا في الصفحات التي تحتوي على إعلانات، كما يتم نقل المواقع الحالية التي حظرت بوتات الذكاء الاصطناعي مسبقاً إلى نفس الإعداد الافتراضي تلقائياً[^1]. إذا كان الوكيل الخاص بك يمتلك أداة لجلب صفحات الويب، فهذا هو التغيير الذي سيؤثر على الكود الخاص بك، وليس قصة "الزاحف متعدد الاستخدامات" التي تصدرت معظم التغطيات الإخبارية. ## ملخص أصبحت خدمة إدارة البوتات في Cloudflare تتعرف الآن على "Agent" كسلوك بوت مستقل، متميز عن البحث والتدريب: "الوكلاء الموجهون من قبل المستخدم والذين يزورون صفحة نيابة عن إنسان، مثل بوتات جلب الدردشة ووكلاء استخدام المتصفح"[^1][^3]. واعتباراً من 15 سبتمبر 2026، تقوم النطاقات الجديدة التي تحقق ربحاً من الإعلانات بحظر هذا السلوك افتراضياً في الصفحات التي تعرض إعلانات، ويتم نقل النطاقات الحالية التي كانت تستخدم إعداد "Block AI" القديم بنفس الطريقة[^1]. يقوم هذا المنشور ببناء وتشغيل أداة جلب ويب صغيرة بلغة Python تعرف عن نفسها بصدق، وتتحقق من `robots.txt` قبل الجلب، وتتعامل مع استجابة `403` واستجابة `402` كـنتيجتين مختلفتين وذات دلالة — بدلاً من إعادة المحاولة باستخدام User-Agent مختلف، وهو بالضبط السلوك الذي تهدف هذه السياسة إلى التصدي له. ## ما ستتعلمه - ما الذي تغير تحديداً لوكلاء الذكاء الاصطناعي في 15 سبتمبر 2026، وكيف يختلف ذلك عن قصة "حظر زواحف الذكاء الاصطناعي" التي تصدرت معظم التغطيات - لماذا يعتبر "Agent" سلوك بوت مستقلاً، ومنفصلاً عن مشكلة "الزاحف متعدد الاستخدامات" (البحث + التدريب) التي استغرق الإعلان معظم كلماته في شرحها - ما هي البوتات الحقيقية والموثقة (Verified) التي تندرج تحت سلوك الـ Agent اليوم، بالاسم والجهة المشغلة - نمط Python مختبر وخالٍ من التبعيات لأداة جلب ويب تتحقق من `robots.txt`، وتعرف عن نفسها بصدق، وتتعامل مع `403` مقابل `402` كـنتائج متميزة - لماذا يعد تزييف User-Agent لبوت موثق لتجنب الحظر فكرة أسوأ الآن مما كانت عليه قبل عام - ماذا يعني هذا عملياً إذا كنت تبني الوكيل الخاص بك، وليس إطلاقه على نطاق OpenAI أو Anthropic ## ثلاثة سلوكيات، وليس مفتاح "حظر الذكاء الاصطناعي" واحد ركزت معظم التغطيات لإعلان Cloudflare في 15 سبتمبر على "الزواحف متعددة الاستخدامات" — وهو زاحف واحد، مثل Googlebot، يقوم بكل من فهرسة البحث وتدريب الذكاء الاصطناعي، وهو ما أجبر أصحاب المواقع تاريخياً على خيار "الكل أو لا شيء". حل Cloudflare لذلك هو إعداد جديد باسم **Disallow AI Training**، وتصنيف جديد باسم **Accountable**. حصلت Apple وGoogle وMicrosoft على هذا التصنيف لزواحفهم متعددة الاستخدامات من خلال توفير خيارات إلغاء الاشتراك، والشفافية، وضمان أن عدم السماح بالتدريب لن يضر بترتيب البحث؛ بينما حصلت Amazon وAnthropic وMeta وOpenAI على نفس التصنيف لزواحفهم المنفصلة المخصصة للتدريب فقط، لأن إبقاء البحث والتدريب على بوتَين مختلفين يعني أن حظر أحدهما لن يؤثر أبداً على الآخر[^1]. هذا أمر حقيقي، وهو العنوان الرئيسي. لكنه ليس الجزء المهم إذا كنت أنت من يبني الوكيل، بدلاً من أن تكون الشخص الذي ينشر الصفحات التي قد يجلبها الوكيل. منذ 1 يوليو 2026، قامت Cloudflare بتصنيف حركة مرور البوتات إلى ثلاثة سلوكيات يمكن التحكم فيها بشكل مستقل[^1][^2][^3]: | السلوك | تعريف Cloudflare | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------- | | **البحث (Search)** | الزحف لبناء فهارس البحث أو قواعد بيانات RAG[^3] | | **التدريب (Training)** | الزحف لتدريب أو ضبط النماذج (fine-tune)[^1][^3] | | **الوكيل (Agent)** | الوكلاء الموجهون من قبل المستخدم الذين يزورون صفحة نيابة عن إنسان، مثل بوتات جلب الدردشة ووكلاء استخدام المتصفح[^1][^3] | يحظى "البحث" و"التدريب" بمعظم التغطية الإعلامية لأن هذا هو المكان الذي تندلع فيه معركة "محتواك درب نموذجاً دون استئذان". أما "الوكيل" فهو فئة ثالثة أكثر هدوءاً — وهي التي يتم تفعيلها في كل مرة تقوم فيها أداتك باستدعاء صفحة نيابة عن المستخدم، سواء كان ذلك وكيل برمجة يتبع رابطاً في مشكلة (issue)، أو وكيل بحث يسحب مصدراً، أو وكيل استخدام متصفح يتنقل عبر موقع ما. ## ما الذي تغير فعلياً في 15 سبتمبر تغيرت ثلاثة أشياء تحديداً بالنسبة لحركة مرور "الوكيل" (Agent)[^1]: 1. **النطاقات الجديدة التي تعتمد على الإعلانات لتحقيق الربح تحصل على إعداد افتراضي.** عند الإعداد الأولي، يحصل مالك الموقع الذي يختار "أنا أحقق أرباحاً من الصفحات التي تعرض إعلانات" الآن على إعداد "التدريب" مضبوطاً على "منع تدريب الذكاء الاصطناعي" (Disallow AI Training) و**"الوكيل" مضبوطاً على "الحظر في الصفحات التي تحتوي على إعلانات"** بشكل افتراضي. أما الموقع الذي لا يحقق أرباحاً من الإعلانات، فيظل الإعداد الافتراضي له هو "السماح" (Allow) في الفئات الثلاث[^1]. 2. **يتم ترحيل النطاقات الحالية بناءً على إعداداتها القديمة.** النطاق الذي كان لديه سابقاً مفتاح "حظر بوتات الذكاء الاصطناعي" القديم مفعلاً — سواء كان "حظر" أو "حظر في الصفحات التي تحتوي على إعلانات" — يتم ترحيل تحكم "الوكيل" الخاص به إلى **"الحظر في الصفحات التي تحتوي على إعلانات"**. أما النطاق الذي كان حظر الذكاء الاصطناعي فيه غير مفعل، فيبقى "الوكيل" على وضع "السماح"[^1]. 3. **لا يزال لا يوجد خيار "عدم السماح" (Disallow) للوكيل.** يمتلك "التدريب" ثلاثة خيارات حقيقية (سماح، عدم السماح بتدريب الذكاء الاصطناعي، حظر) بالإضافة إلى المتغير الخاص بالإعلانات؛ أما "البحث" و"الوكيل" فلديهما فقط خيارات: السماح، الحظر في الصفحات التي تحتوي على إعلانات، أو الحظر في كل مكان. والسبب الذي ذكرته Cloudflare هو: "الوكلاء لا يخلقون نفس المقايضة في إمكانية الاكتشاف عبر البحث كما تفعل الزواحف متعددة الاستخدامات، والإنترنت ليس لديه بعد توجيه راسخ للتعبير عن تفضيلات عدم السماح للوكلاء"[^1]. الآلية التي تضمن نزاهة كل هذا هي **Bot Preference Sync**، والتي تم الإعلان عنها في 21 أغسطس 2026: أي إعدادات تختارها لـ Search و Agent و Training في لوحة التحكم يتم عكسها تلقائياً في ملف `robots.txt` الخاص بك، بحيث لا يحدث تضارب بين الملف الذي تنشره والقاعدة التي تفرضها Cloudflare عند الحافة (edge)[^2]. ويحصل العملاء الجدد على تفعيل خاصية Sync بشكل افتراضي[^2]. من الناحية العملية: إذا كنت تشغل agent يقوم بجلب روابط URL عشوائية، فإن جزءاً كبيراً ومتزايداً من الويب المدعوم بالإعلانات يحظر الآن عملية الجلب هذه بشكل افتراضي، مع عدم وجود طريقة للموقع ليقول "نعم للبحث (search)، لا للـ agent" عبر ملف `robots.txt` وحده كما يمكنه فعل ذلك بالنسبة للتدريب (training) — حيث يتم فرض القيود عند الحافة، وقد يذكر الملف ذلك صراحة أو لا يذكر. ## ما هي البوتات التي تُصنف كـ "Agent" اليوم جدول مراجع البوتات الخاص بـ Cloudflare لا يستخدم كلمات "Search / Agent / Training" كقيم للأعمدة — بل يصنف كل crawler بـ **فئة** قديمة (`AI Crawler`, `AI Search`, `AI Assistant`, `Search Engine`)[^4]. وبمقارنة ذلك مع تعريفات السلوك باللغة البسيطة المذكورة أعلاه: فإن تعريف Cloudflare لـ `AI Assistant` هو "بوت ذكاء اصطناعي مؤتمت يتم تحريكه بواسطة إجراء المستخدم"[^3] — وهو بالضبط كيف تصف Cloudflare سلوك الـ Agent. البوتات الحقيقية والموثقة (Verified) في هذه الفئة اليوم[^4]: | Crawler | Operator | User-Agent | | -------------------- | ---------- | ---------------------- | | ChatGPT-User | OpenAI | `ChatGPT-User` | | Claude-User | Anthropic | `Claude-User` | | Perplexity-User | Perplexity | `Perplexity-User` | | Meta-ExternalFetcher | Meta | `meta-externalfetcher` | | DuckAssistBot | DuckDuckGo | `DuckAssistBot` | | MistralAI-User | Mistral | `MistralAI-User` | هذه البوتات تختلف عن crawler *التدريب (training)* الخاص بكل مشغل (`GPTBot`, `ClaudeBot`) وعن crawler *البحث (search)* (`OAI-SearchBot`, `Claude-SearchBot`, `PerplexityBot`) — أي ثلاثة بوتات منفصلة يمكن حظر كل منها على حدة لكل مشغل رئيسي[^4]. إذا لم يكن العميل الخاص بك أحد هذه العملاء، فلا ينطبق أي مما سبق عليك بالاسم. هذه الإعدادات المسبقة وعمليات النقل تحكم الزواحف (crawlers) المحددة والمُتتبعة في دليل Cloudflare — حيث يُعرف كل منها نفسه بـ User-Agent مميز، كما يوضح الجدول أعلاه[^4]. العميل المخصص الذي يستخدم User-Agent وصفي خاص به (مثل الذي سنبنيه في هذا المنشور أدناه) ليس أحد تلك الإدخالات المسماة، لذا فإن الإعداد المسبق للعميل لا يحدده مباشرة؛ بل يتم تقييمه وفقًا لأي قواعد عامة لإدارة البوتات (Bot Management) تم تكوينها بالفعل في الموقع، والتي تاريخيًا تتعامل مع حركة المرور الآلية غير المعروفة بشك أكبر، وليس العكس[^3]. إن الانضمام رسميًا إلى دليل البوتات الموثقة (Verified Bot) من Cloudflare — عبر توقيع Web Bot Auth تشفيري أو نطاق IP ثابت ومؤكد، بالإضافة إلى سجل من السلوك النزيه وغير المسيء — هو ما يمنح البوت معاملة "حسن النية" التي يحصل عليها المشغلون "المسؤولون" (Accountable)، وهو المسار الأكثر استدامة لأي عميل يقوم بجلب البيانات على نطاق واسع فعليًا[^3]. لقد غطينا كيف يكتسب البوت هذه الحالة — ولماذا يتحول المتطلب من قوائم السماح لـ IP إلى التوقيع التشفيري — في [تحليلنا العميق لـ Web Bot Auth](https://nerdleveltech.com/web-bot-auth-ietf-standard-agent-verification). ## بناء أداة جلب ويب تتعامل مع هذا الأمر بشكل صحيح رد الفعل الخاطئ على `403` هو إعادة المحاولة باستخدام User-Agent لمتصفح على أمل ألا يلاحظ أحد. هذا هو بالضبط نمط الفشل الذي تهدف تسمية "المسؤول" (Accountable) وبرنامج البوتات الموثقة من Cloudflare إلى استئصاله من النظام البيئي — فالمشغل الذي يتصرف بعدم أمانة عند حظره يتم استبعاده من معاملة حسن النية التي تقدمها تلك البرامج[^1][^3]. رد الفعل الصحيح هو التعريف بنفسك بصدق، والتحقق من تفضيلات الموقع المعلنة أولاً، والتعامل مع نتائج HTTP المختلفة بشكل مختلف. ### الخطوة 1: User-Agent صادق ووصفي لا تنتحل شخصية `ChatGPT-User` أو `Claude-User` — فهذه الرموز يتم التحقق منها تشفيريًا أو عبر IP لمشغلين محددين، وتقديمها من الكود الخاص بك هو بالضبط سلوك "عدم الصدق بشأن الهوية" الذي يؤدي إلى إزالة البوت من القائمة[^3]. بدلاً من ذلك، استخدم سلسلة وصفية تحدد العميل الخاص بك: ```python USER_AGENT = "NerdLevelTechAgent/1.0 (+https://nerdleveltech.com/agent-info; contact=agents@nerdleveltech.com)" ``` هذا وحده لن يمنحك معاملة البوت الموثق (Verified-bot) — يتطلب ذلك التقديم في برنامج Cloudflare وتنفيذ Web Bot Auth أو التحقق من IP[^3] — ولكنه الأساس الصادق الذي تعتمد عليه كل خطوة أخرى. ### الخطوة 2: تحقق من `robots.txt` قبل الجلب توفر المكتبة القياسية لـ Python بالفعل محلل `robots.txt` — فلا يوجد سبب لكتابة محلل `Disallow` يدويًا. ومع ذلك، من الجدير بمعرفة حدوده: فإن `urllib.robotparser` يسبق RFC 9309، وهو معيار بروتوكول استبعاد الروبوتات الخاص بـ IETF[^7]، ولا يطبق قاعدة "المطابقة الأطول تفوز" (longest-match-wins) الخاصة بـ RFC في حالة القواعد المتعارضة — بل يتبع أي سطر يأتي أولاً في الملف بدلاً من ذلك. بالنسبة للسلوك الوحيد الذي يعتمد عليه هذا المنشور — ما يحدث عندما لا يمكن جلب `robots.txt` على الإطلاق — فإن سلوكه الافتراضي يتوافق مع RFC: ```python from urllib.robotparser import RobotFileParser from urllib.parse import urljoin def robots_for(base_url: str) -> RobotFileParser: rp = RobotFileParser() rp.set_url(urljoin(base_url, "/robots.txt")) try: rp.read() except Exception: pass # can't reach the site at all -> parser stays "unread"; can_fetch() # then defaults to disallow, which matches RFC 9309 for this case return rp ``` إذا قام مالك الموقع بنشر سطر `Disallow` يطابق اسم العميل (agent) الخاص بك — سواء يدويًا أو عبر Bot Preference Sync — فإن `can_fetch()` تكتشف ذلك قبل أن تقوم بإرسال الطلب الفعلي. ### الخطوة 3: التعامل مع `403` و `402` كنتائج مختلفة تتيح **AI Crawl Control**، وهي منتج Cloudflare الموجود خلف هذه الإعدادات والمتاح في كل الخطط[^6]، لمالك الموقع تكوين استجابة الحظر إما كـ `403 Forbidden` ("لا يمكنك الحصول على هذا") أو `402 Payment Required` ("يمكنك الحصول على هذا إذا دفعت") — وهذا خيار متعمد توفره لوحة تحكم Cloudflare، بهدف إعطاء مشغل الزاحف (crawler) مسارًا للانتقال من "محظور" إلى "مرخص"[^5]. وأي أداة تعامل كليهما كفشل عام تضيع هذه الإشارة: ```python from dataclasses import dataclass from urllib import request, error import json USER_AGENT = "NerdLevelTechAgent/1.0 (+https://nerdleveltech.com/agent-info; contact=agents@nerdleveltech.com)" @dataclass class FetchResult: status: str # "ok" | "disallowed" | "blocked" | "payment_required" | "error" url: str detail: str = "" class PoliteAgentFetcher: def __init__(self, user_agent: str = USER_AGENT): self.user_agent = user_agent self._robots_cache: dict[str, RobotFileParser] = {} def _robots_for(self, base_url: str) -> RobotFileParser: if base_url not in self._robots_cache: self._robots_cache[base_url] = robots_for(base_url) return self._robots_cache[base_url] def fetch(self, url: str, base_url: str) -> FetchResult: robots = self._robots_for(base_url) if not robots.can_fetch(self.user_agent, url): if not robots.last_checked: return FetchResult("disallowed", url, "robots.txt was never successfully read -- defaulting to disallow, per RFC 9309") return FetchResult("disallowed", url, "robots.txt Disallow matches our own declared agent name") req = request.Request(url, headers={"User-Agent": self.user_agent}) try: with request.urlopen(req, timeout=5) as resp: return FetchResult("ok", url, resp.read().decode(errors="replace")[:80]) except error.HTTPError as e: if e.code == 403: return FetchResult("blocked", url, "403 -- Agent behavior is set to Block here. Do not retry with a different User-Agent.") if e.code == 402: body = e.read().decode(errors="replace") info_url = json.loads(body).get("info_url", "") if body else "" return FetchResult("payment_required", url, f"402 -- a paid access path may exist: {info_url}") return FetchResult("error", url, f"HTTP {e.code}") except Exception as e: return FetchResult("error", url, str(e)) ``` قم بتمرير حالة `payment_required` مرة أخرى إلى أي طبقة في العميل الخاص بك تقرر ما إذا كان سيتم إنفاق المال — سواء كان ذلك عبر تكامل Pay Per Crawl، أو خطوة موافقة بشرية، أو ببساطة "تخطي هذا المصدر" — بدلاً من إسقاطها بصمت أو معاملتها بنفس طريقة `403` الصريحة[^5][^9]. ### التشغيل لرؤية جميع النتائج الأربعة دون الاعتماد على منطقة Cloudflare حقيقية ومباشرة، يقوم خادم محلي بسيط بإعادة إنتاج رمزي الاستجابة اللذين تتيح لوحة تحكم AI Crawl Control لمالك الموقع الاختيار بينهما[^5]، بالإضافة إلى `robots.txt` بنمط Bot Preference Sync[^2]: ``` $ python3 demo.py / -> ok Ordinary page content. /internal/secret -> disallowed robots.txt Disallow matches our own declared agent name /blocked -> blocked 403 -- Agent behavior is set to Block here. Do not retry with a different User-Agent. /paywalled -> payment_required 402 -- a paid access path may exist: https://example.com/pay-per-crawl ``` أربع نتائج متميزة ومصنفة بشكل صحيح من أربعة طلبات ضد الخادم الوهمي — ولم يتطلب أي منها التخمين في شكل استجابة الحظر الحقيقية، لأن أكواد الحالة وآلية مزامنة `robots.txt` موثقة وليست مجرد ملاحظات. هناك نتيجة خامسة تستحق الاختبار بشكل منفصل: ماذا يحدث عندما لا يمكن الوصول إلى `robots.txt` على الإطلاق — فشل DNS، أو رفض الاتصال، أو انتهاء المهلة (timeout) — بدلاً من إرجاع استجابة HTTP عادية. عند توجيهه إلى مضيف لا يمكن حله، يعيد نفس الجالب (fetcher) ما يلي: ``` (unreachable robots.txt) -> disallowed robots.txt was never successfully read -- defaulting to disallow, per RFC 9309 ``` هذا هو فرع `last_checked` الذي تمت إضافته أعلاه. تتراجع `can_fetch()` إلى حالة "منع كل شيء" بمجرد أن يفشل المحلل (parser) في قراءة الملف، لذا يبلغ أداة الجلب أن هذه الحالة هي `disallowed` مع رسالة تفصيلية توضح السبب — بدلاً من إعادة استخدام صيغة سطر `Disallow` فعلي وإخفاء الفرق عمن يقوم بتصحيح الأخطاء (debug) لاحقًا. الرسالة لا تقول "غير قابل للوصول" (unreachable) عمدًا — حيث تظل `last_checked` غير محددة سواء في حالة فشل الشبكة الحقيقي أو في حالة مشكلة 401/403-on-`robots.txt` الموضحة أدناه، ولا يكشف `RobotFileParser` عن أي من الاثنين قد حدث بالفعل. ## ما لا يجب فعله لا تحاول إعادة المحاولة عند ظهور خطأ `403` باستخدام User-Agent مختلف، أو متصفح headless، أو بروكسي سكني (residential proxy) لجعل الطلب يبدو وكأنه صادر عن إنسان. إن إطار عمل "Accountable" بالكامل في Cloudflare مبني على مكافأة المشغلين الذين يتسمون بالشفافية بشأن هويتهم وسلوكهم، وحول برنامج Verified Bot الذي يمكنه بل ويقوم بالفعل بإلغاء إدراج البوتات التي يتم ضبطها وهي تزييف هويتها[^1][^3]. إن العميل الذي يتجاوز الحظر عن طريق التزييف لا يحل مشكلة الحظر — بل يقدم الدليل الدقيق الذي صُممت متطلبات الشفافية في Cloudflare لاكتشافه، وهذا يقوض موقف أي مشغل عميل آخر يطلب أن يتم التعامل معه كـ Accountable. إذا كان هناك مصدر يحظر عميلك باستمرار وأنت بحاجة إليه، فإن المسارات التي لا تتضمن الخداع هي: التقديم للحصول على حالة Verified Bot وتفعيل Web Bot Auth[^3][^8]، أو التواصل مع صاحب الموقع مباشرة، أو استخدام Pay Per Crawl / Pay Per Use في حال كان المشغل يدعم ذلك[^5][^9]. ## أنماط الإنتاج الجديرة بالمحاكاة **قم بتخزين تحليل `robots.txt` في الذاكرة المؤقتة (Cache) لكل نطاق، وليس لكل طلب.** كائنات `RobotFileParser` رخيصة من حيث إعادة الاستخدام؛ فإعادة جلب `robots.txt` لكل رابط من نفس الموقع تزيد من زمن الاستجابة وحجم البيانات دون أي فائدة. قاموس `_robots_cache` المذكور أعلاه هو النسخة الدنيا من هذا الإجراء. **سجل حالات `disallowed` و `blocked` و `payment_required` بشكل مختلف في تتبع العميل (agent's trace).** فهي تعني أشياء مختلفة لمن يقوم بتصحيح الأخطاء (debugging) لاحقاً: "الموقع رفض كتابياً"، "الـ edge رفض وقت الطلب"، و"الموقع يتطلب دفع رسوم"، على التوالي. دمجها جميعاً في سطر واحد مثل "فشل الجلب" (fetch failed) يؤدي إلى فقدان معلومات ستحتاجها أثناء تحليل ما بعد الانهيار (postmortem). **لا تخلط بين "مفقود" و"لا يمكن الوصول إليه".** تعامل RFC 9309 مع هاتين الحالتين كحالتين متضادتين[^7]: ظهور خطأ `404` على `/robots.txt` يعني حالة "غير متوفر" (Unavailable)، وقد يتعامل الزاحف (crawler) مع ذلك على أنه وصول كامل — فخطأ `404` ليس هو نفسه `Disallow: /`. أما جلب `robots.txt` الذي يفشل تماماً (فشل DNS، رفض الاتصال، انتهاء المهلة، أو خطأ 5xx) فهو "لا يمكن الوصول إليه" (Unreachable)، وتنص RFC على أن الزاحف يجب أن يفترض المنع الكامل حتى يتمكن فعلياً من قراءة الملف. يتوافق `RobotFileParser` مع هذه القاعدة الثانية: إذا لم تكتمل عملية `.read()` أبداً، فإن `can_fetch()` تفترض افتراضياً حظر كل شيء — وهذا بالضبط سبب أهمية فحص `last_checked` أعلاه، لأنه الطريقة الوحيدة للتمييز بين "الموقع قال لا" وبين "الطلب لم يتلقَ إجابة أبداً". هناك تفصيلة أخرى جديرة بالمعرفة: يتعامل `RobotFileParser` أيضاً مع خطأ `401` أو `403` أثناء جلب `robots.txt` نفسه كمنع كامل — وهذا خيار خاص بـ Python، وليس شيئاً تفرضه RFC 9309 لهذا الرمز من رموز الحالة. ## التحقق كود Python أعلاه يعمل كما هو موضح — تم تنفيذ كل مقطع برمجي مقابل نموذج محاكاة (mock) محلي يعتمد على `http.server`، وليس نطاقاً حياً محمياً بواسطة Cloudflare. وصول الشبكة الصادر من هذه البيئة المعزولة (sandbox) مقيد بقائمة سماح لا تشمل مواقع خارجية عشوائية، لذا لم يكن من الممكن إجراء طلب حقيقي ضد منطقة Cloudflare مع ضبط العميل على Block أثناء كتابة هذا المنشور. ما يثبته الـ mock وما لا يثبته: هو يؤكد أن أداة الجلب تتفرع بشكل صحيح عند استلام `200`، و `403`، و `402`، وسطر `Disallow` في ملف `robots.txt`، لأن هذه هي أشكال الاستجابة الأربعة التي تحددها وثائق Cloudflare الخاصة بـ AI Crawl Control والتي يمكن إنتاجها — `403 Forbidden` و `402 Payment Required` ككودين قابلين للتكوين لاستجابة الحظر[^5]، وإدخال في ملف `robots.txt` متزامن من خيار حظر أو منع فئة Agent[^2]. وهو لا يثبت كيف يبدو جسم الاستجابة (response body) أو الرؤوس (headers) في منطقة Cloudflare حقيقية ومعدة حالياً، لأن هذا المحتوى يتم تحديده من قبل مالك الموقع ولا يتم نشره كمواصفات ثابتة. كل حقيقة تتعلق بالسياسة نفسها — السلوكيات الثلاثة، إعدادات 15 سبتمبر الافتراضية، جدول الهجرة، أسماء البوتات وسلاسل User-Agent — مستشهد بها أدناه من مدونة Cloudflare ووثائق المطورين الخاصة بها، والتي تم جلبها في 16 سبتمبر 2026. ## الأسئلة الشائعة **هل يؤثر هذا على كل وكيل ذكاء اصطناعي (AI agent) يجلب صفحات الويب؟** فقط المواقع المحمية بواسطة Cloudflare، وضمن هذه المواقع، فقط للبوتات الموجودة في قائمة Cloudflare الموثقة تحت سلوك Agent (`ChatGPT-User`، و `Claude-User`، و `Perplexity-User`، وما شابه ذلك)[^1][^4]. الوكيل غير الموثق والمبني بشكل مخصص لا تغطيه هذه الإعدادات المسبقة المحددة — بل يخضع لأي قواعد عامة لإدارة البوتات (Bot Management) يطبقها الموقع بالفعل[^3]. **هل حركة مرور Agent محظورة في كل مكان الآن، أم في بعض الصفحات فقط؟** فقط في الصفحات التي تكتشف Cloudflare أنها تقدم إعلانات، سواء بالنسبة للافتراضي للنطاقات الجديدة أو هجرة النطاقات الموجودة الموضحة أعلاه. لا يزال بإمكان الموقع اختيار حظر Agent في كل مكان، ولكن هذا ليس الافتراضي الجديد[^1]. **هل يمكن للموقع السماح بالبحث (Search) ولكن حظر الوكيل (Agent)؟** نعم — يتم التحكم في Search و Agent و Training بشكل مستقل. يمكن للموقع، على سبيل المثال، أن يظل مفهرساً بالكامل بينما يحظر كل عملية جلب لوكيل في الوقت الفعلي على الصفحات التي تقدم إعلانات[^1][^3]. **هل هناك طريقة للموقع ليقول "لا للوكلاء" من خلال `robots.txt` وحده، بنفس الطريقة التي يعمل بها Disallow AI Training للتدريب؟** ليس بعد. تذكر Cloudflare صراحة أنه لا يوجد تفضيل مُعلن ذاتياً بنمط Disallow لحركة مرور Agent حتى الآن، لأنه لا يوجد معيار ويب مكافئ له كما هو الحال في حالات رفض التدريب[^1]. **ما الفرق بين 403 و 402 من موقع محمي بواسطة Cloudflare؟** كلاهما قابل للتكوين في لوحة تحكم AI Crawl Control. `403` تعني أن مالك الموقع لا يريد أن يصل الزاحف (crawler) إلى المحتوى على الإطلاق؛ أما \_\_PRESER carve\_\_`402` فتشير إلى احتمال وجود مسار وصول مدفوع[^5]. ## الخلاصة إصلاح الزاحف متعدد الاستخدامات (mixed-use crawler) هو الجزء من إعلان Cloudflare في 15 سبتمبر الذي تصدر العناوين، لأنه الجزء الذي يحل نزاعاً حقيقياً مستمراً منذ سنوات بين الناشرين ومحركات البحث. ولكن إذا كنت تقوم ببناء وكلاء (agents) بدلاً من نشر صفحات، فإن التغيير الأكثر هدوءاً هو الذي يؤثر على الكود الخاص بك: أصبح الـ Agent الآن سلوك بوت مستقلاً، مع إعدادات افتراضية خاصة به، على حصة متزايدة من الويب المدعوم بالإعلانات. الإصلاح من جانبك ليس مجرد حل مؤقت — بل هو أداة جلب (fetch tool) تعرّف عن نفسها، وتقرأ ما نشره الموقع، وتتعامل مع `403` و `402` كإشارات مختلفة عما هي عليه في الواقع. ## قراءات ذات صلة - [توثيق بوتات الويب في 2026: تم الشحن قبل أن يصبح معياراً](https://nerdleveltech.com/web-bot-auth-ietf-standard-agent-verification) - [مدفوعات وكلاء الذكاء الاصطناعي: سباق معايير x402 في 2026](https://nerdleveltech.com/ai-agent-payments-x402-standards) - [البحث في الويب لوكلاء الذكاء الاصطناعي: الأسعار والفهارس في 2026](https://nerdleveltech.com/web-search-for-ai-agents-prices-indexes) [^1]: Cloudflare, "Have it both ways: stay discoverable in search while disallowing AI training" — (published September 15, 2026; Search/Agent/Training definitions, Accountable designation and requirements, "what changed on September 15" list, existing- and new-domain migration tables, Applebot/Googlebot/Bingbot specifics, "no Disallow setting for Agents" statement; fetched 2026-09-16) [^3]: Cloudflare Docs, "Verified bots" — (last updated July 1, 2026; Search/Agent/Training/Transact/etc. behavior table and definitions, Direct vs. Intermediary bot operation, legacy category definitions including AI Assistant/AI Crawler/AI Search, Verified bot honesty/non-abuse requirements and delisting conditions; fetched 2026-09-16) [^2]: Cloudflare, "Say it once: Introducing Bot Preference Sync" — (published August 21, 2026; confirms the July 1, 2026 origin of the Search/Agent/Training taxonomy, Bot Preference Sync mechanics and robots.txt example, publisher vs. non-publisher onboarding defaults, Accountable transparency requirements for mixed-use bots; fetched 2026-09-16) [^4]: Cloudflare Docs, "Bot reference" — (last updated April 23, 2026; per-crawler operator, category, and User-Agent table for GPTBot/ChatGPT-User/OAI-SearchBot, ClaudeBot/Claude-User/Claude-SearchBot, PerplexityBot/Perplexity-User, Meta-ExternalFetcher, DuckAssistBot, MistralAI-User, and others; fetched 2026-09-16) [^7]: RFC 9309, "Robots Exclusion Protocol" — (IETF Standards Track, published September 2022; Section 2.3.1.3 "Unavailable Status" — a 4xx like 404, crawler MAY access anything; Section 2.3.1.4 "Unreachable Status" — network or server errors, crawler MUST assume complete disallow; fetched 2026-09-16) [^6]: Cloudflare Docs, "AI Crawl Control" overview — (last updated August 14, 2026; product overview, available on all Cloudflare plans; fetched 2026-09-16) [^5]: Cloudflare Docs, "Manage AI crawlers" — (last updated July 28, 2026; configurable 403 Forbidden vs. 402 Payment Required block response codes, Pay Per Crawl closed-beta status; fetched 2026-09-16) [^9]: Cloudflare Developers Changelog, "Introducing Pay Per Crawl (private beta)" — (private beta launch dated July 1, 2025) [^8]: NerdLevelTech, "Web Bot Auth in 2026: Shipped Before It's a Standard" — /web-bot-auth-ietf-standard-agent-verification (2026-08-12; how a bot becomes cryptographically Verified with Cloudflare)