وكيل المستخدم

الخلاصة — وكيل المستخدم هو سطر نصي قصير يرسله كل متصفح وكل روبوت مع كل طلب ليعرّف بنفسه. يقول زاحف جوجل إنه Googlebot؛ ويقول زاحف بينج إنه bingbot. في robots.txt لا تكتب السطر كاملاً — بل تستخدم اسمًا قصيرًا (“رمزًا”) مثل Googlebot. وإليك النقطة المهمة: هذا السطر مجرد نص، لذا يمكن لأي شخص تزييفه. الطريقة الوحيدة الموثوقة لمعرفة أن الروبوت هو فعلًا من يدّعيه هي التحقق من مصدر الطلب.

ما هو وكيل المستخدم

في كل مرة يحمّل متصفحك صفحة، يرسل معها تسمية نصية قصيرة تصف ما هو — مثل “أنا Chrome على Mac.” هذه التسمية هي وكيل المستخدم، وتنتقل في ترويسة HTTP مع كل طلب. يمكن للخوادم قراءتها والتفاعل معها.

نقطة مهمة من البداية: العميل يملأ هذه التسمية بنفسه. لا شيء يتحقق منها. إنها ادعاء، وليست مصادقة — لذا فإن وكيل مستخدم يقول “Googlebot” ليس نفس الشيء مثل طلب تم التحقق منه فعليًا على أنه Googlebot.

الزواحف تفعل الشيء نفسه. عندما يجلب Googlebot صفحتك، يرسل وكيل مستخدم يتضمن Googlebot. عندما يجلب Bingbot الصفحة، يتضمن وكيل المستخدم bingbot. هكذا يعلن الروبوت عن نفسه في سجلات الخادم.

السلسلة مقابل الاسم القصير

هناك في الواقع شيئان يقصدهما الناس بـ”وكيل المستخدم”، والخلط بينهما يسبب الكثير من الالتباس:

• سلسلة وكيل المستخدم هي السطر الكامل في ترويسة الطلب. سلسلة Googlebot طويلة وتشبه المتصفح كثيرًا.
• رمز وكيل المستخدم هو الاسم القصير الذي تستخدمه في robots.txt لاستهداف روبوت — مثل Googlebot أو bingbot. الرمز هو مجرد جزء من السلسلة الكاملة، وليس كلها.

لذا عندما تكتب قاعدة في robots.txt، تستخدم الرمز القصير:

User-agent: Googlebot
Disallow: /private/

لا تلصق السلسلة الضخمة التي تشبه المتصفح هناك.

لا يمكنك الوثوق بالسلسلة

هذا هو الشيء الوحيد الذي يجب تذكره. سطر وكيل المستخدم هو نص عادي، لذا يمكن لأي شيء تزييفه. يمكن لأي سكربت أن يدّعي أنه Googlebot في سطر واحد من التعليمات البرمجية — والكثير يفعلون ذلك، للتسلل عبر الحظر. جوجل نفسها تقول إن ترويسة Googlebot “غالبًا ما تكون مزيفة.”

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

بعض الملاحظات

• أسماء وكيل المستخدم في robots.txt غير حساسة لحالة الأحرف — Googlebot وgooglebot متماثلان.
• حظر كل شيء باستخدام User-agent: * لا يحظر جميع روبوتات جوجل — فزواحف الإعلانات وزاحف الأمان تتجاهل حرف البدل.
• إظهار نسخة من الصفحة لزاحف ونسخة مختلفة للأشخاص الحقيقيين هو تخفي، وتعتبره جوجل بريدًا عشوائيًا.

تريد الصورة الكاملة — جداول الرموز، وكل زاحف من جوجل وبينج، وأوامر التحقق الدقيقة، وقواعد التخفي — انتقل إلى علامة التبويب المتقدمة.

الخلاصة — وكيل المستخدم هو ترويسة طلب HTTP يرسلها أي عميل لتعريف نفسه؛ وهو بيانات وصفية اختيارية يملؤها العميل، وليست هوية موثقة. قيمته هي سلسلة وكيل المستخدم. منفصلة عن ذلك هي رمز وكيل المستخدم (رمز المنتج) المستخدم في robots.txt — يقول RFC 9309 إنه يجب أن يكون سلسلة فرعية من السلسلة، وهو اصطلاح قوي مع استثناءات موثقة (Google-Extended ليس له سلسلة طلب على الإطلاق). المطابقة غير حساسة لحالة الأحرف، ويتم تجاهل أرقام الإصدارات/البدلات في سطر الرمز، والمجموعة الأكثر تحديدًا تفوز، وتندمج المجموعات ذات الرمز نفسه ولكن لا تندمج أبدًا مع *. السلسلة قابلة للتزوير بسهولة — جوجل تسمي سلسلتها الخاصة “غالبًا ما تكون مزورة” — لذا تحقق عبر DNS عكسي + أمامي (خلف أي بروكسي/CDN، استخدم عنوان IP الحقيقي للعميل) مقابل googlebot.com/google.com/googleusercontent.com لجوجل أو search.msn.com بينج، أو طابق نطاقات IP المنشورة — وحتى الطلب الموثق يثبت فقط وصول الطلب، وليس أن الصفحة تمت فهرستها أو استرجاعها أو استخدامها لتدريب الذكاء الاصطناعي. يتجاهل AdsBot وGoogle-Safety User-agent: *. كما أن كروم يجمد التفاصيل من سلاسل وكيل مستخدم المتصفح (تقليل وكيل المستخدم)؛ تلميحات العميل هي البديل المنظم ولكن الاختياري، ولا يحل أي منهما محل التحقق من الزاحف. يمكن أن يكون تكييف وكيل المستخدم مشروعًا، لكن عرض محتوى مختلف جوهريًا للزواحف بشكل خادع يمكن أن يكون تمويهًا.

الترويسة، والسلسلة، والرمز

ثلاثة أشياء، وإبقاؤها منفصلة هو معظم هذا الموضوع.

• الترويسة. User-Agent هي ترويسة طلب HTTP. يرسلها كل عميل: متصفحك، curl، زاحف، روبوت. وفقًا لـ RFC 9110 (معيار دلالات HTTP الأساسية)، إنه حقل اختياري يملؤه العميل — بيانات وصفية يقدمها العميل، وليست هوية موثقة تحقق منها الخادم.
• السلسلة. قيمة الترويسة — سطر حر يصف البرنامج، والإصدار، ومحرك العرض، وأحيانًا نظام التشغيل.
• الرمز. المعرّف القصير المستخدم في أسطر User-agent: في robots.txt لاستهداف زاحف — Googlebot، bingbot، Google-Extended.

العلاقة هي الجزء الذي يربك الناس. يقول RFC 9309 (معيار بروتوكول استبعاد الروبوتات الرسمي): “SHOULD be a substring of the identification string that the crawler sends… in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (ترجمة) «ينبغي أن يكون سلسلة فرعية من سلسلة التعريف التي يرسلها الزاحف… وفي حالة HTTP، ينبغي أن يكون رمز المنتج سلسلة فرعية في ترويسة User-Agent.» هذا SHOULD وليس MUST — اصطلاح قوي يوصي به المعيار، وليس متطلبًا صارمًا ملزمًا لكل زاحف. Google-Extended (أدناه) هو أوضح مثال على استثناء موثق له. لا تقرأ قاعدة السلسلة الفرعية على أنها عالمية لمجرد أن جوجل تتبعها لمعظم رموزها الخاصة. الرمز جزء من السلسلة عندما يوفر المزود واحدًا؛ تستهدف الرمز في robots.txt وتقرأ السلسلة في سجلاتك.

تفيد هنا صياغة Google لكيفية تعريف روبوتاتها بنفسها: “تعرّف روبوتات جوجل نفسها من خلال ثلاثة أشياء: ترويسة طلب HTTP user-agent، وعنوان IP المصدر للطلب، واسم المضيف العكسي DNS لعنوان IP المصدر.” لاحظ أن وكيل المستخدم هو واحد فقط من الثلاثة — والاثنان الآخران هما وسيلتا التحقق الفعلي منه.

Google-Extended: رمز بدون سلسلة

أوضح توضيح أن الرمز ≠ السلسلة هو Google-Extended. يتحكم في ما إذا كان بإمكان جوجل استخدام محتواك لتدريب Gemini وإسناد إجاباته — وليس له سلسلة وكيل مستخدم طلب HTTP مخصصة على الإطلاق. يتم الزحف نفسه باستخدام سلاسل Googlebot الموجودة؛ Google-Extended موجود فقط كرمز تحكم في robots.txt. لن ترى أبدًا “Google-Extended” في ترويسة طلب ضمن سجلاتك.

النتيجة العملية: حظر Google-Extended يؤثر فقط على استخدام الذكاء الاصطناعي في التدريب لمحتواك — فهو لا يمنع Googlebot من الزحف إلى موقعك وفهرسته لصالح البحث. إنهما قراران منفصلان يتحكم فيهما رمزان منفصلان. (للصورة الأوسع للروبوتات التي تقرأ موقعك، راجع روبوتات الذكاء الاصطناعي والزاحف.)

سلاسل وكيل مستخدم Googlebot

Googlebot دائم التحديث — يعمل على إصدار حديث من Chrome، وإصدار Chrome في سلسلته يتحدث دوريًا (منذ ديسمبر 2019). لهذا السبب يظهر الإصدار كعنصر نائب W.X.Y.Z:

Googlebot للهواتف الذكية (الجوال):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot لسطح المكتب:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

أمران يجب استيعابهما. أولاً، لا تقم بتشفير الإصدار — W.X.Y.Z يتغير، والمطابقة عليه ستفشل. طابق الرمز الثابت Googlebot بدلاً من ذلك. ثانيًا، لا يمكنك فصل الجوال عن سطح المكتب في robots.txt. كلا المتغيرين يشتركان في رمز Googlebot الواحد، لذا تنطبق قاعدة robots.txt على كليهما.

رموز زاحف Google

تدير Google عائلة كاملة من الزواحف والجالبين، لكل منها رمز خاص. أكثرها شيوعًا التي ستواجهها:

وتلك التي تخالف القواعد المعتادة — الزواحف ذات الحالات الخاصة التي تتجاهل User-agent: *:

• AdsBot (AdsBot-Google) وAdsBot Mobile (AdsBot-Google-Mobile) — لا يطيعان حرف البدل. لحظرهما يجب تسميتهما صراحة.
• AdSense (Mediapartners-Google) — نفس الشيء؛ يتجاهل * العام.
• Google-Safety — يُستخدم لاكتشاف البرامج الضارة/إساءة الاستخدام؛ يتجاهل robots.txt تمامًا.

الآثار هي ما يفوته الناس: User-agent: * لا يحظر AdsBot أو Google-Safety. إذا قمت “بحظر جميع الروبوتات” بحرف بدل وافترضت أن AdsBot اختفى، فهو لم يختفِ. (هذا هو بالضبط نوع المفاجأة التي تضع صفحة في منطقة مفهرسة لكن محظورة بواسطة robots.txt — راجع robots.txt للقصة الكاملة للتحكم.)

سلاسل وكيل مستخدم Bingbot

أعادت Bing بناء سلسلة Bingbot في 2022 لتعكس أنه يعرض باستخدام Microsoft Edge. السلاسل الحالية:

Bingbot لسطح المكتب:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot للجوال:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

رمز robots.txt هو فقط bingbot. الشيء الذي يجب الانتباه له: بعد 2022، سلسلة Bingbot تبدو تقريبًا تمامًا مثل متصفح Chrome/Edge حقيقي — العلامة الوحيدة هي جزء bingbot/2.0 بداخلها. إذا كان لديك أي منطق يقوم بتصفية أو اكتشاف الروبوتات بواسطة UA، فهذا التغيير مهم.

كيف يطابق robots.txt رمزًا فعليًا

قواعد قليلة تحكم أي مجموعة من القواعد يطيعها الزاحف (وفقًا لمواصفات robots.txt من Google وRFC 9309):

• المطابقة الأكثر تحديدًا تفوز. Google “تحدد المجموعة الصحيحة من القواعد من خلال إيجاد… المجموعة التي تحتوي على وكيل المستخدم الأكثر تحديدًا الذي يطابق وكيل مستخدم الزاحف.” مجموعة Googlebot تتفوق على مجموعة * لـ Googlebot.
• مجموعات نفس الرمز تندمج — ولكن أبدًا مع *. مجموعات متعددة تسمي نفس الوكيل تُدمج في واحدة. مجموعة وكيل محدد ومجموعة * لا تُدمجان؛ * هو فقط الاحتياط عندما لا يتطابق شيء محدد.
• غير حساس لحالة الأحرف. اسم الحقل والقيمة كلاهما — Googlebot، googlebot، GOOGLEBOT متكافئة.
• أرقام الإصدارات وحروف البدل في سطر الرمز تُتجاهل. وفقًا لـ Google، “كل من googlebot/1.2 وgooglebot* مكافئان لـ googlebot.” لا يمكنك كتابة User-agent: Googlebot* لمطابقة عائلة — * هناك لا يفعل شيئًا.

إذًا، سطر User-agent: يأخذ رمزًا ويطابقه كنص فرعي عادي (غير حساس لحالة الأحرف) لهوية الزاحف — بدون تثبيت إصدار، وبدون أحرف بدل داخله.

لماذا لا يمكنك الوثوق بالسلسلة — وكيف تتحقق

سلسلة وكيل المستخدم هي نص حر. أي شيء يمكنه تعيينها. سطر واحد من curl سيدّعي أنه Googlebot، والكثير من الأدوات والروبوتات الخبيثة تفعل ذلك بالضبط لتجاوز الحظر. تقول Google ذلك في وثائق Googlebot الخاصة بها: “the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (ترجمة) «رأس طلب وكيل المستخدم HTTP الذي يستخدمه Googlebot غالبًا ما يتم انتحاله بواسطة زواحف أخرى.» كما قلت في دليل Googlebot الخاص بي: “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (ترجمة) «ستدّعي العديد من أدوات تحسين محركات البحث وبعض الروبوتات الخبيثة أنها Googlebot. قد يسمح لهم ذلك بالوصول إلى مواقع الويب التي تحاول حظرهم.»

لذا لا تتخذ أبدًا قرار وصول أو محتوى بناءً على السلسلة وحدها. تحقق بدلاً من ذلك.

شرط مسبق واحد قبل أي من الطريقتين: احصل على عنوان IP المصدر الحقيقي. إذا كان موقعك خلف وكيل عكسي أو موازن تحميل أو CDN، فقد يكون العنوان في سجل الوصول الافتراضي الخاص بك هو عنوان IP للوكيل، وليس عنوان الزاحف — تحتاج إلى عنوان IP الأصلي للعميل (عادةً ما يتم تمريره في رأس مثل X-Forwarded-For، مُهيأ بشكل صحيح في وكيلك) أو لا تعني أي من طريقتَي التحقق أدناه شيئًا.

الطريقة 1 — DNS عكسي + أمامي (الأفضل للفحوصات السريعة). خطوتا Google:

1. “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (ترجمة) «قم بإجراء بحث DNS عكسي على عنوان IP الذي يصل من سجلاتك، باستخدام الأمر host. تحقق من أن اسم المجال هو إما googlebot.com أو google.com أو googleusercontent.com.»
2. “Run a forward DNS lookup on the domain name retrieved in step 1… Verify that it’s the same as the original accessing IP address from your logs.” (ترجمة) «قم بإجراء بحث DNS أمامي على اسم المجال الذي تم استرجاعه في الخطوة 1… تحقق من أنه نفس عنوان IP الأصلي الذي يصل من سجلاتك.»

بالنسبة لـ Bingbot، نفس الرقصة المكونة من خطوتين، لكن يجب أن ينتهي اسم المضيف بـ search.msn.com (وليس نطاقًا يحمل علامة Bing التجارية — مفاجأة شائعة). الأوامر موجودة في علامة التبويب “البرامج النصية”.

الطريقة 2 — نطاقات IP المنشورة (الأفضل على نطاق واسع). لا تنشر Google قائمة سماح ثابتة للتشفير الصلب (“these IP address ranges can change”) (ترجمة) «يمكن أن تتغير نطاقات عناوين IP هذه»، لكنها تنشر ملفات CIDR JSON قابلة للقراءة آليًا يمكنك مطابقتها (common-crawlers.json وملفات الزواحف الأوسع). تنشر Bing الآن نطاقاتها أيضًا. لقد بنيت أداة التحقق من عنوان IP الخاص بـ Googlebot لهذا الغرض بالضبط — الصق عناوين IP وسيصنفها. لدى Bing Webmaster Tools أيضًا أداة “Verify Bingbot” مدمجة.

DNS أفضل لفحص سجل لمرة واحدة؛ مطابقة نطاق IP أفضل للتحقق بكميات كبيرة. استخدم ما يناسبك — لكن استخدم واحدًا منها. وعامل كلاً من أسماء المضيفين المتوقعة وملفات النطاقات على أنها حالية حتى اليوم، وليست دائمة — لقد غيّرت Google وBing هذه المسارات من قبل (تم نقل ملفات JSON لنطاقات IP وإعادة تسميتها منذ كتابة هذه المقالة لأول مرة)، لذا أعد التحقق من مستند التحقق المباشر إذا توقف بحث كان يعمل سابقًا عن التطابق.

مطابقة UA ليست دليلاً على النتائج النهائية

حتى الطلب المُتحقق منه بالكامل — عنوان IP حقيقي لـ Googlebot، وDNS عكسي مؤكد أماميًا، كل شيء يبدو صحيحًا — يثبت شيئًا واحدًا فقط: ذلك الطلب وصل إلى خادمك. من المغري تقريب ذلك إلى ادعاء أكبر بكثير، لكن كل من هذه حقائق منفصلة تتطلب أدلة منفصلة:

• تم استلام الطلب — طلب يحمل وكيل المستخدم هذا وصل إلى خادمك. (ما يثبته التحقق من السجلات فعليًا.)
• تم تأكيد الهوية — الطلب جاء فعلًا من الزاحف الذي يدّعي أنه هو. (ما يضيفه مطابقة DNS العكسي / نطاقات IP فوق ذلك.)
• تم جلب المحتوى وعرضه — نجح الزاحف في عرض الصفحة (بدون أخطاء، بدون موارد محجوبة). ليس مضمونًا فقط لأن طلبًا وصل.
• تمت الفهرسة — وصل الرابط إلى فهرس البحث. الجلب الناجح لا يضمن الفهرسة.
• تم استخدامه للاسترجاع أو الاستشهاد أو التدريب — خاصة بالنسبة لزواحف الذكاء الاصطناعي (Google-Extended، GPTBot، وغيرها)، الزحف ليس دليلًا على أن المحتوى الخاص بك تم استرجاعه لإجابة محددة، أو الاستشهاد به، أو استخدامه في تدريب النموذج. تلك خطوات منفصلة وغير قابلة للملاحظة في الغالب، وتحدث بعد الزحف.

زيارة Googlebot موثقة في سجلاتك هي إشارة حقيقية — فقط لا تمددها أكثر مما تظهره فعليًا.

Web Bot Auth: أين يتجه التحقق

في عام 2026، بدأت Google في تجربة Web Bot Auth — “بروتوكول تشفير تجريبي يُستخدم للتحقق من الطلبات المرسلة من قبل الروبوتات.” الفكرة هي “الانتقال من الترويسات التي يسهل تزويرها إلى هوية موثقة وفصل هوية الوكيل عن عناوين IP.” توقّع الروبوتات طلباتها تشفيريًا؛ تتحقق المواقع من التوقيع مقابل المفاتيح العامة المنشورة من Google، وتحمل الطلبات الموقعة ترويسة Signature-Agent. تحذير Google نفسه مهم: “نحن لا نوقّع كل طلب لوكيل معين. تأكد من أنك تعود إلى الطرق المعتمدة للتحقق من الروبوتات.” لذا فهو إضافة، وليس بديلًا — يبقى DNS العكسي ونطاقات IP خط الأساس اليوم.

المتصفحات أصبحت أصعب في التحليل من سلسلة UA أيضًا

كل ما سبق يتعلق بالزواحف، لكن نفس الدرس “لا تثق كثيرًا في السلسلة” ينطبق على المتصفحات، وهو يزداد قوة. بدأت Chrome في طرح تقليل User-Agent: تجميد أو تخشين أجزاء من سلسلة UA الخاصة بها (إصدار المتصفح الكامل، إصدار نظام التشغيل، طراز الجهاز) بدلاً من الإبلاغ عنها بدقة، بحيث لا يمكن استخدام السلسلة لتحديد هوية مستخدم معين. صياغة Google نفسها: “يمكن أن تؤدي دقة التفاصيل ووفرتها إلى تحديد هوية المستخدم. التوفر الافتراضي لهذه المعلومات يمكن أن يؤدي إلى تتبع خفي.” عمليًا، هذا يعني أن تحليل سلسلة UA للحصول على إصدار المتصفح/نظام التشغيل/الجهاز الدقيق — التحليلات، اكتشاف الجهاز، فرز الأخطاء — أصبح غير موثوق بشكل متزايد وسيزداد الأمر سوءًا.

البديل الذي توصي به Chrome هو User-Agent Client Hints (UA-CH): بيانات منظمة يرسلها المتصفح فقط عندما يطلبها الخادم صراحةً. تلميحات منخفضة الإنتروبيا (علامة المتصفح، الإصدار الرئيسي، علامة الجوال) تُرسل افتراضيًا؛ التلميحات عالية الإنتروبيا (الإصدار الدقيق، إصدار المنصة، طراز الجهاز) تتطلب من الخادم الاشتراك عبر ترويسة استجابة Accept-CH أولاً — تفاوض صريح، وليس بثًا. تحذيران قبل الاعتماد عليه: إنها آلية خاصة بعائلة Chrome/Chromium، وليست شيئًا يرسله كل متصفح، وحتى حيث تكون مدعومة، “قد تكون القيمة فارغة، أو لا تُرجع، أو تُملأ بقيمة متغيرة.” تحل Client Hints مشكلة سلسلة المتصفح؛ لكنها ليست آلية للتحقق من الزواحف — لا تزال Google وBing تتحققان من زواحفهما عبر DNS ونطاقات IP، وليس عبر Client Hints.

استهداف User-Agent والتضليل (Cloaking)

الخطوة المغرية — “اكتشاف Googlebot عبر UA الخاص به وتقديم شيء خاص له” — هشة تقنيًا وتشكل انتهاكًا للسياسة.

هشة، لأن Google لا تزحف باستخدام UA واحد. ستحتاج إلى التعامل بشكل صحيح مع Googlebot (الجوال وسطح المكتب)، وGoogle-InspectionTool، وAdsBot، وGoogleOther، والمزيد، من عناوين IP متغيرة — من المستحيل عمليًا إنشاء قائمة بيضاء نظيفة.

انتهاك للسياسة، لأن تقديم محتوى مختلف لزاحف الويب عن المحتوى المقدم للمستخدمين هو إخفاء (cloaking): “تقديم محتوى مختلف للمستخدمين ومحركات البحث بهدف التلاعب في ترتيب البحث وخداع المستخدمين.” وتتراوح العقوبة بين الخفض الخوارزمي والإزالة الكاملة من الفهرس. لاحظ السطر: التكيف المشروع (التخطيطات المتجاوبة، التفاوض على المحتوى) أمر مقبول — إنما استبدال المحتوى نفسه بين الروبوتات والمستخدمين هو ما يندرج تحت الإخفاء.

لمعرفة مكان وكيل المستخدم في خط الأنابيب الأوسع، راجع الزحف (المحور) و الزاحف. للتحكم فيما يُسمح لهذه الروبوتات بجلبه، راجع robots.txt.

ملخص الذكاء الاصطناعي

نظرة مختصرة على النسخة المتقدمة:

• ثلاثة أشياء، تُبقى منفصلة: ترويسة طلب User-Agent — اختيارية، بيانات وصفية يملؤها العميل وفقًا لـ RFC 9110، وليست هوية موثقة؛ قيمتها، وهي سلسلة وكيل المستخدم؛ والرمز المستخدم في robots.txt. وفقًا لـ RFC 9309، يجب أن يكون الرمز SHOULD سلسلة فرعية من السلسلة — اتفاقية قوية، وليست قاعدة عامة.
• بعض الرموز لا تملك سلسلة. Google-Extended هو الاستثناء الموثق: فهو موجود فقط كعنصر تحكم في robots.txt (تدريب Gemini)؛ الزحف يستخدم سلاسل Googlebot العادية. حظره لا يؤثر على فهرسة البحث.
• سلاسل Googlebot/Bingbot دائمة التحديث — إصدار Chrome يظهر كـ W.X.Y.Z ويتغير؛ طابق الرمز المستقر (Googlebot، bingbot)، ولا تطابق الإصدار أبدًا. إصدارا Googlebot للجوال وسطح المكتب يتشاركان رمزًا واحدًا. بعد عام 2022، يبدو Bingbot كمتصفح حقيقي باستثناء جزء bingbot/2.0.
• مطابقة robots.txt: المجموعة الأكثر تحديدًا تفوز؛ المجموعات ذات الرمز نفسه تندمج ولكن أبدًا مع *؛ المطابقة غير حساسة لحالة الأحرف؛ أرقام الإصدارات والبدلات في سطر User-agent: تُتجاهل (Googlebot* = Googlebot).
• AdsBot وGoogle-Safety يتجاهلان User-agent: * — احجبهما بالاسم أو لا تحجبهما إطلاقًا.
• السلسلة قابلة للانتحال بسهولة (تسميها Google نفسها “غالبًا ما تُنتحل”). احصل على عنوان IP الحقيقي للعميل أولاً (يمكن للوكلاء/شبكات CDN إخفاءه في سجلاتك)، ثم تحقق عبر DNS عكسي + أمامي (googlebot.com/google.com/googleusercontent.com؛ Bing ← search.msn.com) أو نطاقات IP المنشورة — ملفات أعادت Google تسميتها/نقلها سابقًا، لذا أعد التحقق من المستند المباشر إذا توقف البحث عن التطابق. لا تثق أبدًا بالسلسلة للتحكم في الوصول.
• الطلب الموثق لا يزال ليس دليلاً على كل شيء في المراحل اللاحقة. استلام الطلب، وتأكيد الهوية، وعرض المحتوى، وفهرسة الصفحة، واسترجاع المحتوى/الاستشهاد به/التدريب عليه ادعاءات منفصلة تحتاج أدلة منفصلة — إصابة السجل تثبت الأول، ولا شيء آخر تلقائيًا.
• مصادقة Web Bot (2026، تجريبية) توقع الطلبات تشفيريًا — إضافة، مع بقاء DNS/IP كخيار احتياطي.
• سلاسل UA للمتصفحات أصبحت أصعب في التحليل أيضًا: تقليص User-Agent في Chrome يجمد تفاصيل الإصدار/نظام التشغيل/الجهاز الدقيقة خارج السلسلة؛ Client Hints هي البديل المنظم والاختياري — لكنها خاصة بـ Chrome ولا تغني عن التحقق من الزاحف.
• تقديم محتوى مختلف حسب UA هو إخفاء — انتهاك لسياسة البريد العشوائي، و هش لأن Google تزحف بالعديد من UAs.

الوثائق الرسمية

وثائق من المصدر الأساسي من محركات البحث والمعيار.

Google

• نظرة عامة على زاحفات Google والجالبين (وكلاء المستخدم) — إشارات التعريف الثلاثة وقائمة الزاحفات الكاملة.
• زاحفات Google الشائعة — جدول الرمز المميز وسلسلة وكيل المستخدم.
• زاحفات Google للحالات الخاصة — AdsBot وMediapartners-Google وGoogle-Safety واستثناءات *.
• التحقق من طلبات زاحفات Google والجالبين — طريقة DNS المكونة من خطوتين وملفات نطاقات IP.
• ما هو Googlebot — سلاسل Googlebot وملاحظة “غالبًا ما يتم انتحالها”.
• كيف يفسر Google مواصفات robots.txt — مطابقة الرموز المميزة، وعدم حساسية حالة الأحرف، والبدائل البرية المتجاهلة.
• مصادقة الطلبات باستخدام Web Bot Auth (تجريبي) — بروتوكول التوقيع المشفر.
• تحديث وكيل مستخدم Googlebot (2019) — لماذا تظهر السلسلة W.X.Y.Z.
• سياسات البريد العشوائي — التمويه — التعريف والعقوبة.

Bing / Microsoft

• الإعلان عن تغيير وكيل المستخدم لـ Bingbot (أبريل 2022) — سلاسل سطح المكتب والجوال الحالية (Fabrice Canel).
• كيفية التحقق من أن Bingbot هو Bingbot (أغسطس 2012) — طريقة *.search.msn.com لعكس DNS.
• أدوات مشرفي المواقع من Bing — التحقق من Bingbot — أداة التحقق المدمجة.

المعيار

• RFC 9110 — دلالات HTTP، §10.1.5 وكيل المستخدم — مواصفة HTTP الأساسية: User-Agent هو حقل اختياري يقدمه العميل، وليس هوية موثقة.
• RFC 9309: بروتوكول استبعاد الزاحفات — التعريف الرسمي على مستوى SHOULD للرمز المميز للمنتج كسلسلة فرعية من سلسلة وكيل المستخدم.
• MDN — ترويسة وكيل المستخدم — بناء جملة HTTP للترويسة نفسها.

سلاسل وكيل مستخدم المتصفح

• Chrome Privacy Sandbox — تقليل وكيل المستخدم — ما يُجمّد أو تُقلّل دقته في سلسلة وكيل مستخدم Chrome، ولماذا.
• Chrome for Developers — تلميحات عميل وكيل المستخدم — تلميحات منخفضة مقابل عالية الإنتروبيا واشتراك Accept-CH.

اقتباسات من المصدر

تصريحات رسمية من Google وBing وRFC. كل رابط هو رابط عميق ينتقل إلى المقطع المقتبس في صفحة المصدر.

Google — كيف تعرف الزاحفات عن نفسها

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (ترجمة) «تعرّف زاحفات Google عن نفسها من خلال ثلاثة أشياء: ترويسة طلب HTTP user-agent، وعنوان IP المصدر للطلب، واسم مضيف DNS العكسي لعنوان IP المصدر.» — وثائق Google Search Central. الانتقال إلى الاقتباس

Google — السلسلة منتحلة

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (ترجمة) «غالبًا ما يتم انتحال رأس طلب وكيل المستخدم HTTP الذي يستخدمه Googlebot بواسطة زاحفات أخرى.» — وثائق Google Search Central. الانتقال إلى الاقتباس

Google — التحقق عبر DNS

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (ترجمة) «قم بإجراء بحث عكسي عن DNS على عنوان IP الذي يصل من سجلاتك، باستخدام الأمر host. تحقق من أن اسم النطاق هو إما googlebot.com أو google.com أو googleusercontent.com.» الانتقال إلى الاقتباس
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” (ترجمة) «لا تنشر Google قائمة عامة بعناوين IP لأصحاب المواقع لإدراجها في القائمة البيضاء لأن نطاقات عناوين IP هذه يمكن أن تتغير.» الانتقال إلى الاقتباس

Google — مطابقة رمز robots.txt

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” (ترجمة) «يتم تجاهل كل النص غير المطابق (على سبيل المثال، كل من googlebot/1.2 وgooglebot* يعادلان googlebot).» — مواصفات robots.txt من Google. الانتقال إلى الاقتباس

Google — Web Bot Auth

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” (ترجمة) «بروتوكول تشفير تجريبي يُستخدم لمصادقة الطلبات المرسلة بواسطة الروبوتات.» الانتقال إلى الاقتباس
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” (ترجمة) «نحن لا نوقع كل طلب لعامل معين. تأكد من أنك تلجأ إلى الطرق المعتمدة للتحقق من الروبوتات.» الانتقال إلى الاقتباس

Google — التمويه (cloaking)

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (ترجمة) «يشير التمويه إلى ممارسة تقديم محتوى مختلف للمستخدمين ومحركات البحث بقصد التلاعب بترتيب البحث وتضليل المستخدمين.» — Google Search Essentials، سياسات البريد العشوائي. الانتقال إلى الاقتباس

RFC 9309 — الرمز هو سلسلة فرعية من السلسلة

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (ترجمة) «يجب أن يكون رمز المنتج سلسلة فرعية من سلسلة التعريف التي يرسلها الزاحف إلى الخدمة. على سبيل المثال، في حالة HTTP، يجب أن يكون رمز المنتج سلسلة فرعية في رأس User-Agent.» الانتقال إلى الاقتباس

Patrick Stox — حول الانتحال

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (ترجمة) «ستدعي العديد من أدوات SEO وبعض الروبوتات الخبيثة أنها Googlebot. قد يسمح لهم ذلك بالوصول إلى مواقع الويب التي تحاول حظرهم.» — من دليلي حول Googlebot على Ahrefs. اقرأه

الزاحف ← الرمز ← السلسلة ← التحقق

الجدول المرجعي. الرمز هو ما تضعه في robots.txt؛ اسم المضيف للتحقق هو ما يتحول إليه الطلب الحقيقي عبر البحث العكسي.

قواعد مطابقة robots.txt في لمحة

حقائق سريعة

• الرمز = جزء فرعي من سلسلة UA (RFC 9309). ليس السلسلة بأكملها.
• Googlebot للجوال وسطح المكتب يشتركان في رمز واحد — لا يمكنك فصلهما في robots.txt.
• إصدار Chrome في السلسلة هو W.X.Y.Z — وهو يتغير؛ لا تقم أبدًا بتثبيته.
• سلسلة UA سهلة التزييف — تحقق عبر DNS أو IP، ولا تثق أبدًا في السلسلة.

تحقق من البوت عبر DNS عكسي + أمامي

يمكن تزييف سلسلة user-agent في سطر واحد من curl. تأكد من أن البوت حقيقي عن طريق التحقق من IP الذي جاء منه فعليًا. النمط هو نفسه بالنسبة لـ Google و Bing — فقط اسم المضيف المتوقع يختلف.

احصل على IP الصحيح أولاً: إذا مرت الطلبات عبر وكيل عكسي، أو موازن تحميل، أو CDN قبل الوصول إلى خادمك، فقد تُظهر سجلاتك الافتراضية عنوان الوكيل، وليس عنوان الزاحف. استخدم IP العميل الحقيقي (من رأس توجيه مُهيأ بشكل صحيح) قبل تشغيل أي من الفحصين أدناه.

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

إذا لم ينتهِ البحث العكسي بالنطاق المتوقع — googlebot.com / google.com / googleusercontent.com لـ Google، search.msn.com لـ Bing — أو لم يتطابق البحث الأمامي مع IP الأصلي، فهو ليس البوت الحقيقي، بغض النظر عن ما تقوله سلسلة user-agent.

المطابقة مع نطاقات IP المنشورة (على نطاق واسع)

للتحقق من عدد كبير من الزيارات، تخطَّ فحص DNS لكل طلب وقم بمطابقة IP مع نطاقات CIDR المنشورة من محرك البحث بدلاً من ذلك. تنشر Google JSON قابل للقراءة آليًا:

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

اسحب الملف، وأنشئ مجموعة CIDR، واختبر كل IP مسجل للتحقق من العضوية. (لقد بنيت أداة التحقق من IP لـ Googlebot تقوم بذلك بالنيابة عنك.) تنشر Bing نطاقاتها أيضًا، ويحتوي Bing Webmaster Tools على فحص مدمج “Verify Bingbot”.

قائمة التحقق من سلامة user-agent

قبل كتابة قواعد UA أو التعامل مع بوت في سجلاتك:

• أنت تستهدف الرمز في robots.txt (مثل Googlebot)، وليس لصق سلسلة وكيل المستخدم الكاملة.
• لا توجد أرقام إصدارات أو * داخل سطر User-agent: — يتم تجاهلها (Googlebot* لا يفعل شيئًا).
• لم تفترض أن User-agent: * يحظر AdsBot أو Google-Safety — فهو لا يفعل؛ قم بتسميتها صراحةً إذا كنت بحاجة إلى ذلك.
• إذا قمت بحظر Google-Extended، فأنت تفهم أنه يؤثر فقط على استخدام التدريب بالذكاء الاصطناعي — لا يزال Googlebot يزحف ويفهرس لصالح البحث.
• أنت لا تعتمد التحكم في الوصول أو المحتوى على سلسلة وكيل المستخدم الخام — فهي قابلة للانتحال.
• أي فحص “هل هذا حقًا Googlebot؟” يتم عبر DNS عكسي + أمامي (googlebot.com / google.com / googleusercontent.com) أو نطاقات IP المنشورة — Bing عبر search.msn.com.
• لا يوجد مطابقة لوكيل المستخدم مثبتة على الإصدار في أي مكان — جزء Chrome W.X.Y.Z يتغير.
• أنت لا تقدم محتوى مختلفًا لوكيل بوت عما تقدمه للمستخدمين (هذا تمويه).

أدوات للعمل مع وكلاء المستخدم

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

Googlebot Verifier — الأداة للمشكلة الدقيقة التي يعود إليها هذا المقال مرارًا: سلسلة وكيل المستخدم هي مجرد نص، لذا لا يمكنك الوثوق بها وحدها. الصق عنوان IP من سجلاتك، واختر الزاحف الذي يدعي أنه (Googlebot، Bingbot، وغيرها)، وسيقوم بتشغيل فحص DNS العكسي + الأمامي ومطابقة نطاقات IP المنشورة نيابةً عنك، ثم يعيد حكمًا متدرجًا — تأكيد DNS عكسي، ضمن النطاقات المنشورة، مزيف، غير قابل للتحقق، أو ليس زاحفًا معروفًا. هل لديك يوم كامل من الزيارات للتحقق بدلاً من عنوان IP واحد؟ الصق ما يصل إلى 500 عنوان IP أو سطور سجل خام في مربع الدفعة.

Log File Analyzer — لسؤال “أي وكلاء المستخدم يزحفون فعليًا إلى موقعي؟” ضع سجل وصول الخادم (nginx، Apache، IIS/W3C، أو JSON) وسيقوم بتحليله بالكامل في متصفحك، مقسمًا نشاط الزحف حسب البوت وحسب القسم، مع الإشارة إلى هدر رموز الحالة، وفصل زواحف الذكاء الاصطناعي عن زواحف البحث، و— الجزء الأهم لهذا الموضوع— تشغيل تقرير المزيفين الذي يسمي الطلبات التي تدعي أنها رمز وكيل مستخدم لزاحف معروف دون عنوان IP لدعم ذلك.

AI-Crawler Access Checker — للعائلة الأحدث من الرموز التي لا تتصرف مثل Googlebot أو bingbot. أدخل عنوان URL وسيتحقق من robots.txt الخاص بك مقابل كل رمز وكيل مستخدم رئيسي لزاحف الذكاء الاصطناعي (GPTBot، ClaudeBot، PerplexityBot، Google-Extended، والمزيد)، ويعرض القاعدة الدقيقة التي تفوز لكل منها، ويشير إلى ما إذا كان ملف llms.txt موجودًا. مفيد لتأكيد أن رمزًا مثل Google-Extended يفعل ما تعتقد أنه يفعله — نظرًا لأنه، كما هو موضح أعلاه، ليس لديه سلسلة طلب خاصة به لرصدها في سجلاتك.

تعليمات جاهزة لمهام وكيل المستخدم

مطالبتان مبنيان حول الفخاخ المحددة التي يضعها هذا الموضوع — الانتحال و صيغة رمز robots.txt — وليس حشوًا عامًا “دقق في SEO الخاص بي”. الصق بياناتك الخاصة في العناصر النائبة.

المطالبة 1 — فرز مجموعة من سلاسل وكيل المستخدم من سجلاتك بحثًا عن علامات الانتحال

الصق عمودًا من سلاسل وكيل المستخدم الخام المأخوذة من سجل الوصول الخاص بك (وليس عناوين IP — هذه المطالبة لا يمكنها التحقق من الهوية، فقط رصد التناقضات في السلسلة نفسها):

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

المطالبة 2 — فحص ملف robots.txt بحثًا عن أخطاء مطابقة الرموز

الصق ملف robots.txt الكامل الخاص بك:

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

اختبر نفسك: وكيل المستخدم

خمسة أسئلة سريعة حول الترويسة، والسلسلة، والرمز، وكيفية التحقق من أن البوت حقيقي. اختر إجابة لكل سؤال، ثم تحقق.

موارد تستحق وقتك

كتاباتي ذات الصلة

• ما هو Googlebot وكيف يعمل؟ — سلاسل وكيل المستخدم الكاملة لـ Googlebot، وطرق التحقق، وأداة التحقق من IP الخاصة بي.
• مفهرس، رغم حظره بواسطة robots.txt — حيث يتصادم الحظر المستند إلى وكيل المستخدم وحظر robots.txt.
• Robots.txt وSEO: كل ما تحتاج معرفته — كيف تعمل مجموعات وكيل المستخدم والقواعد فعليًا.
• تعرف على زاحفات الويب الجديدة: روبوتات الذكاء الاصطناعي تقترب من روبوتات محركات البحث — التشكيلة المتغيرة لوكلاء المستخدم في سجلاتك.

رسمي / معايير

• RFC 9110 — دلالات HTTP، §10.1.5 وكيل المستخدم — التعريف الأساسي: بيانات وصفية اختيارية يقدمها العميل.
• RFC 9309: بروتوكول استبعاد الروبوتات — التعريف الرسمي على مستوى SHOULD لرمز المنتج كسلسلة فرعية.
• نظرة عامة على الزاحفات والجالبين من Google والتحقق من زاحفات Google.
• Chrome Privacy Sandbox — تقليل وكيل المستخدم وتلميحات عميل وكيل المستخدم — لماذا يصبح تحليل سلاسل وكيل المستخدم في المتصفح أصعب، وما الذي يحل محلها.

من الآخرين

• John Mueller — الروبوتات التي تنتحل صفة Googlebot — حول الانتحال ولماذا يعد عكس DNS هو الحل.
• MDN — ترويسة وكيل المستخدم — عرض مواصفات HTTP للترويسة.
• r/TechSEO — المجتمع لتصحيح أخطاء الزحف والسجلات.
• Web Bot Auth: طريقة Google التجريبية الجديدة للتحقق من الروبوتات الأصلية (Search Engine Land، Barry Schwartz، مايو 2026) — أفضل ملخص من مكتب الأخبار لكيفية عمل توقيع الروبوتات المشفر وما يعنيه عمليًا.
• وكيل مستخدم Google-Agent يحدد حركة مرور وكلاء الذكاء الاصطناعي في سجلات الخادم (Search Engine Land) — يغطي الجالب الجديد الذي يبدأه المستخدم ويتجاهل robots.txt ويستخدم Web Bot Auth.
• Google تختبر معيارًا جديدًا لترخيص الروبوتات (Search Engine Journal) — سياق صناعي أوسع حول معيار IETF والشركات (Amazon، Cloudflare، Akamai، OpenAI) التي تدعمه.
• الإعلان عن وكلاء مستخدم مستقبليين لـ Bingbot (مدونة Bing Webmaster، Fabrice Canel، ديسمبر 2019) — الإعلان الأصلي عن تحول Bingbot إلى العرض المستند إلى Edge قبل طرح 2022.
• إصدار قائمة Microsoft لعناوين IP الخاصة بـ Bingbot (Search Engine Land) — تغطية قرار Bing بنشر نطاقات IP للتحقق من الروبوتات على نطاق واسع.

سجل التغييرات