ظلّ PageSpeed Insights سنوات طويلة يقيّم الأداء وإمكانية الوصول وأفضل الممارسات وSEO. وفي 2026 انضم بهدوء بند خامس إلى ذلك الصف: Agentic Browsing. وهو يجيب عن سؤال تتجاهله الفئات الأربع الأخرى: هل يستطيع وكيل ذكاء اصطناعي أن يعمل فعليًا مع هذه الصفحة؟
هذا الدليل مخصص لوضع ذلك الفحص موضع التنفيذ على موقعك: أن تشغّله، وتفهم ما يقوله كل فحص فعليًا، وأن تخرج بقائمة إصلاحات.
ما الذي ستحصل عليه في النهاية
لمن هذا الدليل: لمتخصصي SEO والمطوّرين وأصحاب المواقع الذين يريدون معرفة كيف تتصرف صفحاتهم حين يتصفحها وكيل لا إنسان.
ما سيكون بين يديك عند الانتهاء: نتيجة Agentic Browsing حقيقية لموقعك، وقراءة فحصًا بفحص لما ينجح ويفشل ولا ينطبق، وقائمة إصلاحات مرتّبة حسب الأولوية.
المتطلبات: عنوان URL متاح للعموم، ونحو عشر دقائق لأول تشغيل، ووصول إلى الشيفرة إذا كنت تخطط للإصلاح في اليوم نفسه.
معيار الإنجاز: أن تستطيع شرح الدرجة الكسرية فحصًا بفحص، وأن تميّز أي الإخفاقات يمنع الوكيل فعلًا من إكمال مهمة على صفحتك.
من أين جاء هذا الفحص ولماذا الآن
لم تكن فئة Agentic Browsing موجودة قبل عام. وجرى الإطلاق على ثلاث مراحل، وكلها موثّقة من Google:
- 7 مايو 2026: أضاف Lighthouse 13.3 الفئة إلى إعداداته الافتراضية، فأصبحت جزءًا من أي تشغيل قياسي.
- 22 يونيو 2026: أعلنت مدوّنة Chrome for Developers عن الفئة في مقال حول مجموعة أدوات تجعل موقعك جاهزًا للوكلاء، إلى جانب أدوات DevTools للوكلاء وإرشادات WebMCP.
- 20 يوليو 2026: فعّل Lighthouse 13.4.1 الفئة في مسار واجهة PageSpeed Insights البرمجية، وذكر في ملاحظات الإصدار أن الإصدار سيصل إلى PageSpeed Insights «خلال أسبوعين». أي أن الإطلاق العام جاء في مطلع أغسطس 2026.
حين شغّلت الفحص في 11 سبتمبر 2026، كان تذييل التقرير يشير إلى تشغيل محاكى بإصدار Lighthouse 13.4.1، وكان Agentic Browsing يجلس مباشرة بجوار SEO. أي أن الميزة متاحة فعليًا وليست حصرية لقناة تجريبية. وهي أيضًا غير مكتملة صراحةً؛ إذ يقول وصف الفئة في التقرير ذلك بلا مواربة: هذه الفئة ما زالت قيد التطوير وقابلة للتغيير.
ملاحظة عملية قبل البدء: يشغّل PSI هذه الفئة نيابة عنك على جانب Google. لا تحتاج إلى إصدار معيّن من Chrome ولا إلى تجربة أصلية للفحوص على مستوى الصفحة. متطلبات الإصدار تنطبق فقط عند تشغيل الفئة محليًا داخل Chrome DevTools.
شغّل الفحص على موقعك
- افتح pagespeed.web.dev والصق عنوان URL. ابدأ بالجوّال ثم أعد التجربة على سطح المكتب، لأن التشغيلين المخبريين يُقيَّمان بشكل منفصل.
- انتظر انتهاء البيانات المخبرية. بيانات الميدان في الأعلى تأتي من Chrome UX Report وتُحمَّل سريعًا. أما تشغيل Lighthouse في الأسفل فيستغرق وقتًا أطول، وفيه تظهر الفئات.
- ابحث عن صف الدرجات. سترى الأداء وإمكانية الوصول وأفضل الممارسات وSEO، ثم Agentic Browsing على شكل كسر بدلًا من درجة من 0 إلى 100.
- وسّع الفئة. تتجمّع قائمة الفحوص في مجموعات Agent Accessibility وWebMCP والمجموعتين المعتادتين: الناجحة وغير المنطبقة.
- افتح كل فحص فاشل. كل صف يتوسّع ليعرض القاعدة أو العنصر أو الملف المحدد وراء الفشل، وهذا ما تحتاجه لفتح تذكرة إصلاح.
الفئة الخامسة تقف في الصف نفسه مع الدرجات التي تتحقق منها فرق SEO يوميًا. الصورة مأخوذة من PageSpeed Insights في 11 سبتمبر 2026.
فحص الجودة: تأكد من إصدار Lighthouse في تفاصيل التشغيل قبل مقارنة النتائج مع زميل. يحدّث PSI إصدار Lighthouse وفق جدوله الخاص، والفئة ما زالت تتغير بين الإصدارات.
إذا فشل التشغيل: يعيد PSI أحيانًا مهلة RPC على الصفحات الثقيلة. حدث ذلك معي على موقع كبير أثناء البحث. أعد المحاولة أو اختبر الصفحة عبر Lighthouse محليًا.
اقرأ الدرجة الكسرية بشكل صحيح
لا يملك Agentic Browsing درجة موزونة من 0 إلى 100، وهذا مقصود. توضح وثائق Lighthouse أن معايير الويب الوكيلي ما زالت تتشكل، لذا يتركز الاهتمام على إشارات قابلة للتنفيذ لا على ترتيب تنافسي.
وهذه هي الحسابات المهمة فعلًا:
العرض | المعنى |
|---|---|
3/3 | نجحت كل الفحوص التي تدخل التقييم. الفحوص غير المنطبقة تُستبعد. |
1/3 | نجح فحص واحد وفشل اثنان. المقام يشمل الفحوص الناجحة والفاشلة فقط. |
0/3 | لم ينجح أي فحص قابل للتقييم بعد. شائع في أول تشغيل على صفحة ثقيلة مليئة بالإعلانات. |
بلا كسر | كل الفحوص غير منطبقة أو لم تُشغَّل الفئة. راجع تفاصيل التشغيل. |
الفخ هو قراءة 1/3 على أنها «جاهزية للوكلاء بنسبة 33 بالمئة». إنها ليست نسبة من أي شيء، بل عدّ: من بين الفحوص الثلاثة القابلة للتقييم على تلك الصفحة نجح واحد، والفحوص التي لم تنطبق خرجت من الحساب تمامًا. في التقرير الذي التقطته، عملت ستة فحوص، وثلاثة لم تنطبق، وأنتجت الثلاثة الباقية الكسر 1/3.
تتحرك النتيجة أيضًا بين تشغيل وآخر على الصفحة نفسها. وتذكر Lighthouse ثلاثة أسباب: التسجيل الديناميكي للأدوات (فأدوات WebMCP المسجّلة عبر JavaScript قد تُلتقط أو تُفوَّت حسب التوقيت)، وتغيّرات DOM التي تعيد تشكيل شجرة إمكانية الوصول، وانزياحات التصميم الناتجة عن الإعلانات أو الصور بلا أبعاد أو المحتوى المحقون. إذا تذبذب رقمك، فهذا هو السبب غالبًا.
استعرض الفحوص الستة
يشغّل إصدار PSI الحالي ستة فحوص، وهناك فحص سابع قادم: أضاف فرع التطوير في Lighthouse بالفعل فحص ai-catalog.json ضمن مجموعة جديدة باسم Agent Discoverability، لذا اعتبر هذه القائمة مرتبطة بالإصدار.
الفحص | ما يتحقق منه | ماذا يعني «غير منطبق» |
|---|---|---|
شجرة إمكانية الوصول غير صحيحة | مجموعة فرعية من قواعد إمكانية الوصول تركز على الوكلاء: الأسماء والتسميات البرمجية، وبنية ARIA الصحيحة، والعناصر التي تبقى تفاعلية رغم إخفائها من الشجرة | لا يحدث أبدًا؛ هذا الفحص يُقيَّم دائمًا |
llms.txt لا يتبع التوصيات | أن يكون الملف | أعاد الملف استجابة 404. غياب llms.txt يُعتبر اختياريًا لا فشلًا |
انزياح التصميم التراكمي | الاستقرار البصري، حتى لا ينقر الوكلاء الذين يتصرفون بناءً على موضع العناصر على شيء خاطئ أثناء الانزياح | لا يحدث أبدًا؛ هذا الفحص يُقيَّم دائمًا |
أدوات WebMCP المسجّلة | هل تسجّل الصفحة أدوات WebMCP عبر الواجهة التصريحية أو الأمرية | لم تُكتشف أي أدوات WebMCP |
تغطية نماذج WebMCP | النماذج التصريحية التي تفتقد إلى تعليقات الأدوات | كما في الأعلى |
صلاحية مخططات WebMCP | هل تنشر الأدوات المسجّلة مخططات إدخال وإخراج صالحة | كما في الأعلى |
عرض الفئة بعد التوسيع: فشلان ونجاح واحد وثلاثة فحوص غير منطبقة. قائمة الفشل هي أقصر قائمة مهام.
ظهور فحوص WebMCP الثلاثة بحالة «غير منطبق» أمر طبيعي في 2026. فـ WebMCP معيار مقترح في مرحلة تجربة أصلية ومعاينة مبكرة، وله واجهتان: واحدة تصريحية تعلّق على نماذج HTML القياسية، وأخرى أمرية تسجّل الأدوات من JavaScript. ومعظم المواقع لا تنفّذ أيًّا منهما بعد، لذا تُظهر معظم التقارير ثلاث دوائر رمادية هناك. الرمادي ليس أحمر، فلا تعتبره فشلًا.
أصلح ما يرصده الفحص
أربعة محاور إصلاح تغطي الفحوص الستة. أما صفوف WebMCP الثلاثة فلا تحتاج انتباهًا إلا إذا كنت تقدّم فعلًا أدوات للوكلاء.
اجعل شجرة إمكانية الوصول مقروءة للوكلاء
يعتمد الوكلاء على شجرة إمكانية الوصول كخريطة رئيسية لصفحتك؛ فهي تسرد الأدوار والأسماء والحالات. والزر بلا اسم يمكن الوصول إليه طرق مسدود بالنسبة لهم، وكذلك لمستخدمي قارئات الشاشة.
ما تفعله: اعالج القواعد الفاشلة من الفحص الموسّع. المشتبه بهم المعتادون: الأزرار التي تحمل أيقونة فقط، وحقول النماذج بلا تسمية، والروابط التي نصها «اضغط هنا» فقط، وتوليفات أدوار ARIA غير الصحيحة، والمعرّفات المكررة التي تشير إليها ARIA. فضّل HTML الدلالي، وأضف خاصية for إلى التسميات، وامنح العناصر المخصصة دورًا وtabindex صريحين عندما يتعذّر استخدام عنصر أصلي.
النتيجة المتوقعة: يتحول الفحص إلى ناجح، وكثيرًا ما تتحسن معه درجة إمكانية الوصول المعتادة، لأن نسخة Agentic Browsing مجموعة فرعية مركّزة من الفحوص نفسها.
إذا واجهت طريقًا مسدودًا: عندما تتجاوز قائمة الإصلاحات مئات العناصر، لا تلاحقها عنصرًا عنصرًا. أصلح المكوّن المشترك، مثل زر الأيقونة في الترويسة، ثم أعد التشغيل. غالبًا ما يمحو مكوّن واحد عشرات الصفوف.
انشر ملف llms.txt يجتاز فحص التنسيق
هنا فخ يقع فيه الحريصون. لا يتحقق الفحص من وجود /llms.txt فحسب، بل يفحص محتوى الملف، والملف الذي يسرد روابط خامًا يفشل، لأن الفحص يبحث عن روابط بصيغة Markdown.
ما تفعله: أنشئ /llms.txt في جذر النطاق، مع عنوان H1 وروابط Markdown حقيقية:
# اسم الشركة
وصف مختصر لما يغطيه الموقع وكيف ينبغي استخدامه.
## الصفحات الرئيسية
- [نظرة عامة على المنتج](https://example.com/product)
- [الأسعار](https://example.com/pricing)
- [التوثيق](https://example.com/docs)النتيجة المتوقعة: يتحول الفحص إلى الأخضر. أما استجابة 404 فتظهر كغير منطبق، وهذا مقبول اليوم. وحدوث خطأ من فئة 500 أو فشل في الجلب هو فشل حقيقي يحتاج إصلاحًا على الخادم.
فحص الجودة: اجلب ملفك /llms.txt من الطرفية وعدّ الروابط. إن ظهرت بصيغة https://example.com/pricing بلا أقواس، سيفشل الفحص حتى لو كان الملف منشورًا ومقروءًا للبشر.
وتحذير صادق: لا يستخدم بحث Google ملف llms.txt. يقول دليل Google نفسه للتحسين مع الذكاء الاصطناعي إن الملف «لن يضر ولن يفيد ظهور موقعك أو ترتيبه في بحث Google، لأن بحث Google يتجاهلها». اكتبه لأدوات الوكلاء التي تقرأ هذا العُرف، لا من أجل الترتيب.
ثبّت التصميم ليتمكن الوكلاء من الاستهداف
أصبح انزياح التصميم أهم مما كان. فالوكيل الذي يحدد موضع زر ثم ينقر إحداثياته سيخطئ إذا دفعت إعلانات أو لافتة أو صورة متأخرة التحميل الزرّ 200 بكسل إلى الأسفل بين اللحظتين.
ما تفعله: حدّد عرضًا وارتفاعًا صريحين (أو نسبة أبعاد) للصور والتضمينات، واحجز مساحة ثابتة لفتحات الإعلانات ولافتات الموافقة، وتجنّب إدراج محتوى فوق محتوى موجود بعد التحميل، وحرّك العناصر عبر transform بدل الخصائص التي تؤدي إلى إعادة حساب التصميم.
النتيجة المتوقعة: انزياح تصميم تراكمي أقل من 0.1 في التشغيل المخبري، وهو العتبة نفسها التي تستخدمها Core Web Vitals.
فحص الجودة: يسمّي قسم أداء الصفحة في التقرير العناصر المسؤولة عن الانزياح بدقة. ابدأ من هناك بدل التخمين.
قرّر بشأن WebMCP لاحقًا
لا تُقيَّم فحوص WebMCP الثلاثة إلا إذا سجّل موقعك أدوات. وإن كانت لديك رحلة حجز أو دفع أو نموذج دعم أو أي مهمة منظمة يستطيع الوكيل إتمامها، فإن WebMCP يستحق نموذجًا أوليًا: فهو يخبر الوكيل بالضبط أي أداة يستدعي بدل أن يخمّن من شجرة DOM. ويقدّم Chrome هذه الميزة خلف تجربة أصلية وعلامة اختبار محلية، فهي خيار واقعي لا مجرد فكرة نظرية.
أما إذا لم تكن لديك مهمة تستحق الأتمتة، فاترك WebMCP بلا تدخل. لا مشكلة إطلاقًا في ثلاث دوائر رمادية. والشيء الوحيد الذي لا ينبغي فعله هو تسجيل أداة شكلية لتحسين الكسر. فالفئة إشارة جاهزية، والتلاعب بها يفرّغها من معناها.
تحقّق من الإصلاح
أعد تشغيل العنوان نفسه في PSI وقارن ثلاثة أشياء لا شيئًا واحدًا: الكسر، وحالة كل فحص، ونوع الجهاز. فقد يحرّك الإصلاح الكسر دون إصلاح ما يهمك فعلًا، كما أن الجوّال وسطح المكتب يعطيان نتيجتين مخبريتين منفصلتين.
لتسريع التكرار، شغّل Lighthouse محليًا بدل انتظار PSI. الفئة متضمنة في Lighthouse 13.3 وأحدث، لذا سيتعرف عليها أي تثبيت محلي. وإن أردت نسخة لوحة DevTools، تشير وثائق Google إلى أن اختبار الفئة يتطلب Chrome 150 أو أحدث، وأن فحوص WebMCP تحتاج أيضًا إلى تجربة أصلية مسجّلة.
احتفظ بسجل قصير قبل الإصلاح وبعده. سطر بتاريخ مثل «2026-09-11: جوّال 1/3، فشل شجرة إمكانية الوصول وllms.txt» يكفي. فهو يخبرك ما إذا كان التراجع اللاحق حقيقيًا أم مجرد تذبذب بين تشغيلين.
ما ليس هذا الفحص
ثلاثة أشياء لا يفعلها، لأن الالتباس حولها واسع:
- ليس عامل ترتيب. يصف إعلان Chrome الفئة بأنها معلوماتية وغير مشمولة في المقارنات المعيارية. وترتيب بحث Google لا يتأثر بكسر Agentic Browsing.
- ليس درجة ظهور في الذكاء الاصطناعي. إنه يقيس قدرة الوكيل على تشغيل صفحتك، ولا يقول شيئًا عن احتمالية استشهاد ChatGPT أو Perplexity بك في إجابة.
- ليس حكم نجاح أو فشل على موقعك. انخفاض الكسر في صفحة تسويقية بسيطة يعني عادةً أن ما يمكن تقييمه قليل، لا أن الوكلاء محجوبون عن الموقع.
العدسة المفيدة هي هذه: تتحقق الفئة مما إذا كان موقعك يصمد حين يكون الزائر غير بشري. وكل ما تكافئه يستحق الفعل أصلًا: HTML الدلالي، وتصميم مستقر، وعناصر تحكم موسومة. ويُختم دليل Google نفسه بشأن المواقع الصديقة للوكلاء بالفكرة ذاتها: ما يجعل الموقع جاهزًا للوكلاء يجعله أفضل للبشر أيضًا.
اجعله ضمن دورة المراجعة
الجاهزية للوكلاء من المجالات التي تتحرك فيها المنصة أسرع من قائمة التحقق. وعادتان تبقيانك محدّثًا دون تحويل الأمر إلى مشروع:
- أعد تشغيل الفحص بعد أي تغيير في القالب أو التنقل أو النماذج أو رحلة الدفع. فهذه هي التعديلات التي تحرّك شجرة إمكانية الوصول واستقرار التصميم.
- تابع الكسر لكل قالب لا لكل رابط. عشر صفحات منتج بنتيجة واحدة تعني مشكلة قالب واحد، وإصلاح واحد يحلّها جميعًا.
فحص PSI ضيق عمدًا: ستة فحوص، صفحة واحدة في كل مرة. وإن أردت الصورة الأوسع، بما يشمل قواعد robots وبطاقات خوادم MCP واكتشاف OAuth وإشارات التجارة الوكيلية، توفّر Auspia فحص Agent Readiness المجاني، الذي يمسح العنوان وفق هذه المعايير البروتوكولية ويعرض جدول مقارنة.
الأسئلة الشائعة
هل تؤثر درجة Agentic Browsing في ترتيب Google؟ لا. تصف Google الفئة بأنها معلوماتية وليست جزءًا من أنظمة ترتيب البحث. تعامل معها كفحص جاهزية للوكلاء لا كدرجة SEO.
لماذا تغيّر الكسر بين تشغيلين على الصفحة نفسها؟ يؤدي التسجيل الديناميكي للأدوات وتغيّرات DOM التي تعدّل شجرة إمكانية الوصول وانزياحات التصميم المتأخرة إلى تباين بين التشغيلات. أعد الاختبار وقارن قائمة الفحوص لا الكسر وحده.
لماذا تظهر فحوص WebMCP الثلاثة كلها كغير منطبقة؟ لأن صفحتك لا تسجّل أدوات WebMCP. هذه هي الحالة المتوقعة لمعظم المواقع في 2026 وليست فشلًا.
هل غياب llms.txt مشكلة؟ بالنسبة لهذا الفحص، لا. تُعامل استجابة 404 كغير منطبق. أما الملف الموجود بتنسيق خاطئ فيفشل، فإن نشرته فانشره بشكل صحيح.
هل يمكن تشغيل هذا في التكامل المستمر؟ نعم، متى توفرت الفئة في إصدار Lighthouse لديك. الفحوص حتمية بحكم التصميم، وهذا ما يجعلها مناسبة لفحوص خطوط الإنتاج. ضع في الحسبان أن أجزاء WebMCP تعتمد على دعم المتصفح والتسجيل في التجربة الأصلية، لذا توقّع ظهورها كغير منطبقة في معظم بيئات التكامل المستمر.
هل أحتاج Chrome 150 لاستخدام هذا؟ لا. يشغّل PageSpeed Insights الفحص على الخادم. ومتطلب Chrome 150 ينطبق على تشغيل الفئة محليًا داخل DevTools.
الكاتبة: Alice Monroe، محللة أدوات SEO بالذكاء الاصطناعي في Auspia وتغطي أكثر من 150 أداة. تكتب عن SEO وأدوات البحث بالذكاء الاصطناعي، وعن الفحوص التي تستحق وقتك، وكيفية دمجها في روتين العمل.
