Cloudflare تحظر عملاء AI: حل بديل مُجرب (2026)

تتعامل Cloudflare الآن مع وكلاء الذكاء الاصطناعي (AI agents) كفئة منفصلة يمكن حظرها، بعيداً عن زواحف البحث والتدريب. ومنذ 15 سبتمبر 2026، أصبحت المواقع الجديدة التي تعتمد على الربح من الإعلانات تحظر بشكل افتراضي سلوك الـ Agent هذا في الصفحات التي تحتوي على إعلانات، كما يتم نقل المواقع الحالية التي حظرت بوتات الذكاء الاصطناعي مسبقاً إلى نفس الإعداد الافتراضي تلقائياً¹.

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

ملخص

أصبحت خدمة إدارة البوتات في Cloudflare تتعرف الآن على "Agent" كسلوك بوت مستقل، متميز عن البحث والتدريب: "الوكلاء الموجهون من قبل المستخدم والذين يزورون صفحة نيابة عن إنسان، مثل بوتات جلب الدردشة ووكلاء استخدام المتصفح"¹². واعتباراً من 15 سبتمبر 2026، تقوم النطاقات الجديدة التي تحقق ربحاً من الإعلانات بحظر هذا السلوك افتراضياً في الصفحات التي تعرض إعلانات، ويتم نقل النطاقات الحالية التي كانت تستخدم إعداد "Block AI" القديم بنفس الطريقة¹. يقوم هذا المنشور ببناء وتشغيل أداة جلب ويب صغيرة بلغة 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 يوليو 2026، قامت Cloudflare بتصنيف حركة مرور البوتات إلى ثلاثة سلوكيات يمكن التحكم فيها بشكل مستقل¹³²:

يحظى "البحث" و"التدريب" بمعظم التغطية الإعلامية لأن هذا هو المكان الذي تندلع فيه معركة "محتواك درب نموذجاً دون استئذان". أما "الوكيل" فهو فئة ثالثة أكثر هدوءاً — وهي التي يتم تفعيلها في كل مرة تقوم فيها أداتك باستدعاء صفحة نيابة عن المستخدم، سواء كان ذلك وكيل برمجة يتبع رابطاً في مشكلة (issue)، أو وكيل بحث يسحب مصدراً، أو وكيل استخدام متصفح يتنقل عبر موقع ما.

ما الذي تغير فعلياً في 15 سبتمبر

تغيرت ثلاثة أشياء تحديداً بالنسبة لحركة مرور "الوكيل" (Agent)¹:

1. النطاقات الجديدة التي تعتمد على الإعلانات لتحقيق الربح تحصل على إعداد افتراضي. عند الإعداد الأولي، يحصل مالك الموقع الذي يختار "أنا أحقق أرباحاً من الصفحات التي تعرض إعلانات" الآن على إعداد "التدريب" مضبوطاً على "منع تدريب الذكاء الاصطناعي" (Disallow AI Training) و"الوكيل" مضبوطاً على "الحظر في الصفحات التي تحتوي على إعلانات" بشكل افتراضي. أما الموقع الذي لا يحقق أرباحاً من الإعلانات، فيظل الإعداد الافتراضي له هو "السماح" (Allow) في الفئات الثلاث¹.
2. يتم ترحيل النطاقات الحالية بناءً على إعداداتها القديمة. النطاق الذي كان لديه سابقاً مفتاح "حظر بوتات الذكاء الاصطناعي" القديم مفعلاً — سواء كان "حظر" أو "حظر في الصفحات التي تحتوي على إعلانات" — يتم ترحيل تحكم "الوكيل" الخاص به إلى "الحظر في الصفحات التي تحتوي على إعلانات". أما النطاق الذي كان حظر الذكاء الاصطناعي فيه غير مفعل، فيبقى "الوكيل" على وضع "السماح"¹.
3. لا يزال لا يوجد خيار "عدم السماح" (Disallow) للوكيل. يمتلك "التدريب" ثلاثة خيارات حقيقية (سماح، عدم السماح بتدريب الذكاء الاصطناعي، حظر) بالإضافة إلى المتغير الخاص بالإعلانات؛ أما "البحث" و"الوكيل" فلديهما فقط خيارات: السماح، الحظر في الصفحات التي تحتوي على إعلانات، أو الحظر في كل مكان. والسبب الذي ذكرته Cloudflare هو: "الوكلاء لا يخلقون نفس المقايضة في إمكانية الاكتشاف عبر البحث كما تفعل الزواحف متعددة الاستخدامات، والإنترنت ليس لديه بعد توجيه راسخ للتعبير عن تفضيلات عدم السماح للوكلاء"¹.

الآلية التي تضمن نزاهة كل هذا هي Bot Preference Sync، والتي تم الإعلان عنها في 21 أغسطس 2026: أي إعدادات تختارها لـ Search و Agent و Training في لوحة التحكم يتم عكسها تلقائياً في ملف robots.txt الخاص بك، بحيث لا يحدث تضارب بين الملف الذي تنشره والقاعدة التي تفرضها Cloudflare عند الحافة (edge)³. ويحصل العملاء الجدد على تفعيل خاصية Sync بشكل افتراضي³.

من الناحية العملية: إذا كنت تشغل agent يقوم بجلب روابط URL عشوائية، فإن جزءاً كبيراً ومتزايداً من الويب المدعوم بالإعلانات يحظر الآن عملية الجلب هذه بشكل افتراضي، مع عدم وجود طريقة للموقع ليقول "نعم للبحث (search)، لا للـ agent" عبر ملف robots.txt وحده كما يمكنه فعل ذلك بالنسبة للتدريب (training) — حيث يتم فرض القيود عند الحافة، وقد يذكر الملف ذلك صراحة أو لا يذكر.

ما هي البوتات التي تُصنف كـ "Agent" اليوم

جدول مراجع البوتات الخاص بـ Cloudflare لا يستخدم كلمات "Search / Agent / Training" كقيم للأعمدة — بل يصنف كل crawler بـ فئة قديمة (AI Crawler, AI Search, AI Assistant, Search Engine)⁴. وبمقارنة ذلك مع تعريفات السلوك باللغة البسيطة المذكورة أعلاه: فإن تعريف Cloudflare لـ AI Assistant هو "بوت ذكاء اصطناعي مؤتمت يتم تحريكه بواسطة إجراء المستخدم"² — وهو بالضبط كيف تصف Cloudflare سلوك الـ Agent. البوتات الحقيقية والموثقة (Verified) في هذه الفئة اليوم⁴:

هذه البوتات تختلف عن crawler التدريب (training) الخاص بكل مشغل (GPTBot, ClaudeBot) وعن crawler البحث (search) (OAI-SearchBot, Claude-SearchBot, PerplexityBot) — أي ثلاثة بوتات منفصلة يمكن حظر كل منها على حدة لكل مشغل رئيسي⁴.

إذا لم يكن العميل الخاص بك أحد هذه العملاء، فلا ينطبق أي مما سبق عليك بالاسم. هذه الإعدادات المسبقة وعمليات النقل تحكم الزواحف (crawlers) المحددة والمُتتبعة في دليل Cloudflare — حيث يُعرف كل منها نفسه بـ User-Agent مميز، كما يوضح الجدول أعلاه⁴. العميل المخصص الذي يستخدم User-Agent وصفي خاص به (مثل الذي سنبنيه في هذا المنشور أدناه) ليس أحد تلك الإدخالات المسماة، لذا فإن الإعداد المسبق للعميل لا يحدده مباشرة؛ بل يتم تقييمه وفقًا لأي قواعد عامة لإدارة البوتات (Bot Management) تم تكوينها بالفعل في الموقع، والتي تاريخيًا تتعامل مع حركة المرور الآلية غير المعروفة بشك أكبر، وليس العكس². إن الانضمام رسميًا إلى دليل البوتات الموثقة (Verified Bot) من Cloudflare — عبر توقيع Web Bot Auth تشفيري أو نطاق IP ثابت ومؤكد، بالإضافة إلى سجل من السلوك النزيه وغير المسيء — هو ما يمنح البوت معاملة "حسن النية" التي يحصل عليها المشغلون "المسؤولون" (Accountable)، وهو المسار الأكثر استدامة لأي عميل يقوم بجلب البيانات على نطاق واسع فعليًا². لقد غطينا كيف يكتسب البوت هذه الحالة — ولماذا يتحول المتطلب من قوائم السماح لـ IP إلى التوقيع التشفيري — في تحليلنا العميق لـ Web Bot Auth.

بناء أداة جلب ويب تتعامل مع هذا الأمر بشكل صحيح

رد الفعل الخاطئ على 403 هو إعادة المحاولة باستخدام User-Agent لمتصفح على أمل ألا يلاحظ أحد. هذا هو بالضبط نمط الفشل الذي تهدف تسمية "المسؤول" (Accountable) وبرنامج البوتات الموثقة من Cloudflare إلى استئصاله من النظام البيئي — فالمشغل الذي يتصرف بعدم أمانة عند حظره يتم استبعاده من معاملة حسن النية التي تقدمها تلك البرامج¹². رد الفعل الصحيح هو التعريف بنفسك بصدق، والتحقق من تفضيلات الموقع المعلنة أولاً، والتعامل مع نتائج HTTP المختلفة بشكل مختلف.

الخطوة 1: User-Agent صادق ووصفي

لا تنتحل شخصية ChatGPT-User أو Claude-User — فهذه الرموز يتم التحقق منها تشفيريًا أو عبر IP لمشغلين محددين، وتقديمها من الكود الخاص بك هو بالضبط سلوك "عدم الصدق بشأن الهوية" الذي يؤدي إلى إزالة البوت من القائمة². بدلاً من ذلك، استخدم سلسلة وصفية تحدد العميل الخاص بك:

USER_AGENT = "NerdLevelTechAgent/1.0 (+https://nerdleveltech.com/agent-info; contact=agents@nerdleveltech.com)"

هذا وحده لن يمنحك معاملة البوت الموثق (Verified-bot) — يتطلب ذلك التقديم في برنامج Cloudflare وتنفيذ Web Bot Auth أو التحقق من IP² — ولكنه الأساس الصادق الذي تعتمد عليه كل خطوة أخرى.

الخطوة 2: تحقق من robots.txt قبل الجلب

توفر المكتبة القياسية لـ Python بالفعل محلل robots.txt — فلا يوجد سبب لكتابة محلل Disallow يدويًا. ومع ذلك، من الجدير بمعرفة حدوده: فإن urllib.robotparser يسبق RFC 9309، وهو معيار بروتوكول استبعاد الروبوتات الخاص بـ IETF⁵، ولا يطبق قاعدة "المطابقة الأطول تفوز" (longest-match-wins) الخاصة بـ RFC في حالة القواعد المتعارضة — بل يتبع أي سطر يأتي أولاً في الملف بدلاً من ذلك. بالنسبة للسلوك الوحيد الذي يعتمد عليه هذا المنشور — ما يحدث عندما لا يمكن جلب robots.txt على الإطلاق — فإن سلوكه الافتراضي يتوافق مع RFC:

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 الموجود خلف هذه الإعدادات والمتاح في كل الخطط⁶، لمالك الموقع تكوين استجابة الحظر إما كـ 403 Forbidden ("لا يمكنك الحصول على هذا") أو 402 Payment Required ("يمكنك الحصول على هذا إذا دفعت") — وهذا خيار متعمد توفره لوحة تحكم Cloudflare، بهدف إعطاء مشغل الزاحف (crawler) مسارًا للانتقال من "محظور" إلى "مرخص"⁷. وأي أداة تعامل كليهما كفشل عام تضيع هذه الإشارة:

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 الصريحة⁷⁸.

التشغيل

لرؤية جميع النتائج الأربعة دون الاعتماد على منطقة Cloudflare حقيقية ومباشرة، يقوم خادم محلي بسيط بإعادة إنتاج رمزي الاستجابة اللذين تتيح لوحة تحكم AI Crawl Control لمالك الموقع الاختيار بينهما⁷، بالإضافة إلى robots.txt بنمط Bot Preference Sync³:

$ python3 demo.py
/                    -> ok                 <html><body>Ordinary page content.</body></html>
/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 الذي يمكنه بل ويقوم بالفعل بإلغاء إدراج البوتات التي يتم ضبطها وهي تزييف هويتها¹². إن العميل الذي يتجاوز الحظر عن طريق التزييف لا يحل مشكلة الحظر — بل يقدم الدليل الدقيق الذي صُممت متطلبات الشفافية في Cloudflare لاكتشافه، وهذا يقوض موقف أي مشغل عميل آخر يطلب أن يتم التعامل معه كـ Accountable.

إذا كان هناك مصدر يحظر عميلك باستمرار وأنت بحاجة إليه، فإن المسارات التي لا تتضمن الخداع هي: التقديم للحصول على حالة Verified Bot وتفعيل Web Bot Auth²⁹، أو التواصل مع صاحب الموقع مباشرة، أو استخدام Pay Per Crawl / Pay Per Use في حال كان المشغل يدعم ذلك⁷⁸.

أنماط الإنتاج الجديرة بالمحاكاة

قم بتخزين تحليل robots.txt في الذاكرة المؤقتة (Cache) لكل نطاق، وليس لكل طلب. كائنات RobotFileParser رخيصة من حيث إعادة الاستخدام؛ فإعادة جلب robots.txt لكل رابط من نفس الموقع تزيد من زمن الاستجابة وحجم البيانات دون أي فائدة. قاموس _robots_cache المذكور أعلاه هو النسخة الدنيا من هذا الإجراء.

سجل حالات disallowed و blocked و payment_required بشكل مختلف في تتبع العميل (agent's trace). فهي تعني أشياء مختلفة لمن يقوم بتصحيح الأخطاء (debugging) لاحقاً: "الموقع رفض كتابياً"، "الـ edge رفض وقت الطلب"، و"الموقع يتطلب دفع رسوم"، على التوالي. دمجها جميعاً في سطر واحد مثل "فشل الجلب" (fetch failed) يؤدي إلى فقدان معلومات ستحتاجها أثناء تحليل ما بعد الانهيار (postmortem).

لا تخلط بين "مفقود" و"لا يمكن الوصول إليه". تعامل RFC 9309 مع هاتين الحالتين كحالتين متضادتين⁵: ظهور خطأ 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 ككودين قابلين للتكوين لاستجابة الحظر⁷، وإدخال في ملف robots.txt متزامن من خيار حظر أو منع فئة Agent³. وهو لا يثبت كيف يبدو جسم الاستجابة (response body) أو الرؤوس (headers) في منطقة Cloudflare حقيقية ومعدة حالياً، لأن هذا المحتوى يتم تحديده من قبل مالك الموقع ولا يتم نشره كمواصفات ثابتة. كل حقيقة تتعلق بالسياسة نفسها — السلوكيات الثلاثة، إعدادات 15 سبتمبر الافتراضية، جدول الهجرة، أسماء البوتات وسلاسل User-Agent — مستشهد بها أدناه من مدونة Cloudflare ووثائق المطورين الخاصة بها، والتي تم جلبها في 16 سبتمبر 2026.

الخلاصة

إصلاح الزاحف متعدد الاستخدامات (mixed-use crawler) هو الجزء من إعلان Cloudflare في 15 سبتمبر الذي تصدر العناوين، لأنه الجزء الذي يحل نزاعاً حقيقياً مستمراً منذ سنوات بين الناشرين ومحركات البحث. ولكن إذا كنت تقوم ببناء وكلاء (agents) بدلاً من نشر صفحات، فإن التغيير الأكثر هدوءاً هو الذي يؤثر على الكود الخاص بك: أصبح الـ Agent الآن سلوك بوت مستقلاً، مع إعدادات افتراضية خاصة به، على حصة متزايدة من الويب المدعوم بالإعلانات. الإصلاح من جانبك ليس مجرد حل مؤقت — بل هو أداة جلب (fetch tool) تعرّف عن نفسها، وتقرأ ما نشره الموقع، وتتعامل مع 403 و 402 كإشارات مختلفة عما هي عليه في الواقع.

قراءات ذات صلة

• توثيق بوتات الويب في 2026: تم الشحن قبل أن يصبح معياراً
• مدفوعات وكلاء الذكاء الاصطناعي: سباق معايير x402 في 2026
• البحث في الويب لوكلاء الذكاء الاصطناعي: الأسعار والفهارس في 2026