مقاييس الويب الأساسية والكمون: هل تحصل الصفحات الأسرع على المزيد من استشهادات الذكاء الاصطناعي؟

مقاييس الويب الأساسية والكمون: هل تحصل الصفحات الأسرع على المزيد من استشهادات الذكاء الاصطناعي؟

مقدمة

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

لكن غالبًا ما يتم تفويت تمييز مهم:

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

اعتبارًا من 2 أغسطس 2026، تشير Google إلى أن أوقات استجابة الخادم المستقرة والكمون المنخفض يمكن أن يزيدا من سعة الزحف للموقع. كما تشير Google إلى أن ميزات بحث الذكاء الاصطناعي الخاصة بها تستخدم نفس أنظمة البحث والفهرسة الأساسية مثل البحث التقليدي ولا تتطلب ترميزًا خاصًا بالذكاء الاصطناعي أو تحسينات في السرعة. (developers.google.com)

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

1. ما إذا كان انخفاض زمن الوصول إلى أول بايت يزيد من تكرار الزحف.
2. ما إذا كان انخفاض الرسم الأكبر للمحتوى يحسن الاكتشاف أو الفهرسة.
3. ما إذا كان انخفاض تغيير التخطيط التراكمي يؤثر على الزحف أو استرجاع الذكاء الاصطناعي.
4. ما إذا كانت تحسينات الأداء تزيد من معدل الاستشهاد بالصفحات بشكل مرئي بواسطة أنظمة بحث الذكاء الاصطناعي.

الإجابة المختصرة

يمكن أن يؤدي انخفاض زمن الوصول إلى أول بايت إلى تحسين الزحف في الظروف المناسبة

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

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

• كم مرة يتغير الموقع.
• مدى شعبية الموقع وصفحاته.
• ما إذا كان المحتوى مفيدًا وفريدًا.
• عدد عناوين URL المكررة أو ذات القيمة المنخفضة الموجودة.
• ما إذا كانت عناوين URL المحدثة متضمنة في خرائط المواقع.

هذا يعني أن الكمون المنخفض يجب أن يكون له أقوى تأثير على المواقع الكبيرة، التي يتم تحديثها بشكل متكرر، أو التي تعاني من قيود الخادم، وليس بالضرورة على موقع صغير بمحتوى جديد محدود.

قد يساعد الرسم الأكبر للمحتوى الأقل بشكل غير مباشر

يقيس الرسم الأكبر للمحتوى (Largest Contentful Paint) متى يظهر المحتوى المرئي الرئيسي للمستخدم. كما تشير Google إلى أن كلاً من زمن استجابة الخادم والوقت اللازم لعرض الصفحات والموارد المضمنة يمكن أن يؤثر على كفاءة الزحف. (developers.google.com)

العلاقة المحتملة غير مباشرة:

كمون أقل ← تسليم موارد أسرع ← عرض أو جلب أكثر كفاءة ← عدد أقل من مهلات الزحف أو عمليات الجلب غير المكتملة.

يجب أن يكون التأثير أقوى عندما يعتمد المحتوى المهم على:

• جافاسكريبت بطيء.
• صور كبيرة.
• أوراق الأنماط التي تمنع العرض.
• العرض من جانب العميل.
• الموارد المضمنة الثقيلة.

من غير المرجح أن تكون درجة الرسم الأكبر للمحتوى السريعة بحد ذاتها إشارة مباشرة لاستشهاد الذكاء الاصطناعي.

من المحتمل أن يكون لتغيير التخطيط التراكمي المنخفض تأثير مباشر قليل على الزحف

يقيس تغيير التخطيط التراكمي (Cumulative Layout Shift) الحركة غير المتوقعة للمحتوى المرئي. وهو في الأساس مقياس لتجربة المستخدم. تشمل الأسباب الشائعة الصور بدون أبعاد، والإعلانات المدرجة ديناميكيًا، والمحتوى المضمن، وخطوط الويب. (web.dev)

لا يختبر الزاحف تغييرًا في التخطيط بنفس الطريقة التي يختبرها بها الزائر البشري. لذلك، من غير المحتمل وجود علاقة مباشرة بين انخفاض تغيير التخطيط التراكمي وزيادة الزحف.

قد تكون هناك علاقة غير مباشرة عندما يكون تغيير التخطيط الكبير ناتجًا عن:

• محتوى يتم إدخاله متأخرًا بواسطة جافاسكريبت.
• نص مهم مخفي حتى يتم تشغيل البرامج النصية.
• صور أو تضمينات تؤخر بناء الصفحة.
• قوالب غير مستقرة تنتج محتوى مختلفًا أثناء عمليات الجلب المختلفة.

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

الصفحات الأسرع لا يتم الاستشهاد بها تلقائيًا في كثير من الأحيان

تقول Google إن الصفحات التي تظهر في ميزات الذكاء الاصطناعي يجب أن تكون مفهرسة أولاً ومؤهلة للظهور في نتائج البحث العادية مع مقتطف. وتقول Google أيضًا أنه لا توجد متطلبات تقنية إضافية أو تحسينات خاصة بالذكاء الاصطناعي لنظرات الذكاء الاصطناعي العامة ووضع الذكاء الاصطناعي الخاص بها. (developers.google.com)

وبالمثل، تشير OpenAI إلى أن تصنيفات بحث ChatGPT تعتمد على عوامل متعددة وأن السماح لزاحف البحث الخاص بها، OAI-SearchBot، مهم للإدراج. ولا تشير إلى أن مقاييس الويب الأساسية المنخفضة تزيد مباشرة من احتمالية الاستشهاد. (help.openai.com)

يشير هذا إلى نموذج من أربع مراحل:

1. الاكتشاف — هل يتعلم النظام أن عنوان URL موجود؟
2. الجلب والمعالجة — هل يمكن للنظام استرداد الصفحة وفهمها؟
3. الفهرسة والاسترجاع — هل يتم تحديد الصفحة لاستعلام معين؟
4. اختيار الاستشهاد — هل تظهر الصفحة كمصدر مرئي في الإجابة؟

قد تؤثر سرعة الصفحة على المرحلتين الأوليين. لم يتم إثباتها كسبب مباشر للمرحلة الرابعة.

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

ما الذي يجب اختباره؟

يجب أن تختبر الدراسة سؤالين مختلفين بدلاً من التعامل مع "رؤية الذكاء الاصطناعي" كمقياس واحد.

السؤال 1: هل يؤثر الأداء على الزحف؟

النتائج الأولية:

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

السؤال 2: هل يؤثر الأداء على اختيار الاستشهاد؟

النتائج الأولية:

• النسبة المئوية للاستعلامات المختبرة التي تنتج استشهادًا مرئيًا.
• معدل الاستشهاد لكل صفحة مؤهلة.
• حصة الاستشهاد داخل استعلام.
• النسبة المئوية للصفحات المسترجعة التي تصبح استشهادات مرئية.
• ثبات الاستشهاد بمرور الوقت.
• معدل الاستشهاد حسب نظام الذكاء الاصطناعي.

يجب فصل هذه النتائج حسب المزود. قد تستخدم نظرة Google AI العامة، ونتائج بحث ChatGPT، وإجابة Microsoft Copilot، وإجابة Perplexity، واستجابة بحث Claude فهارس وزواحف وأنظمة تصنيف وجداول تحديث مختلفة.

تصميم التجربة

1. بناء مجموعة صفحات مضبوطة

استخدم مجموعة صفحات كبيرة بما يكفي لإنتاج بيانات زحف واستشهاد ذات مغزى.

سيتضمن التصميم العملي المبدئي ما يلي:

• 240 إلى 800 صفحة.
• ما لا يقل عن 20 صفحة لكل قالب صفحة.
• ثلاث إلى خمس فئات محتوى.
• مزيج من الصفحات الدائمة التحديث والصفحات المحدثة بانتظام.
• أعداد متساوية من الصفحات في كل مجموعة معالجة.

يجب أن تحتوي كل صفحة على:

• هيكل HTML مماثل.
• طول محتوى مماثل.
• نظام نشر واحد.
• نمط ربط داخلي واحد.
• نفس القواعد القانونية (canonical).
• نفس معالجة خريطة الموقع.
• نفس أذونات robots.txt.
• موضوع فريد ومفيد.

لا تنشئ مئات الصفحات الرقيقة أو شبه المكررة فقط للتجربة. تحذر إرشادات Google من أن عناوين URL المكررة وذات القيمة المنخفضة يمكن أن تهدر موارد الزحف وتقلل من كفاءة الموقع. (developers.google.com)

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

• طول المحتوى.
• طلب الموضوع.
• تكرار التحديث.
• عدد الروابط الداخلية.
• عدد الروابط الخارجية.
• حركة المرور التاريخية.
• موضع ترتيب البحث.

ثم ضع صفحة واحدة من كل زوج في المجموعة الضابطة والأخرى في مجموعة المعالجة.

2. استخدم تصميم معالجة عاملية (Factorial treatment design)

يجب اختبار معالجات الأداء الرئيسية بشكل مستقل ومعًا.

ينشئ هذا تجربة مضبوطة للتحسينات الثلاثة المطلوبة:

• HTTP/3.
• التخزين المؤقت في حافة شبكة توصيل المحتوى.
• ضغط الصور.

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

لماذا يحتاج HTTP/3 إلى قياس خاص به

يستخدم HTTP/3 بروتوكول نقل QUIC ويوفر تدفقات مستقلة، مما يمكن أن يتجنب حجب رأس الخط على مستوى النقل الموجود في HTTP/2 عبر TCP. تعتمد فوائده على ما إذا كان العميل أو الزاحف يتفاوض بالفعل على HTTP/3. (rfc-editor.org)

لذلك، سجل البروتوكول المتفاوض عليه لكل طلب:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

لا تفترض أن تمكين HTTP/3 يعني أن كل زاحف يستخدمه. إذا استمر Googlebot أو OAI-SearchBot أو أي زاحف آخر في استخدام HTTP/2، فلا يمكن لـ HTTP/3 أن يؤثر على طلبات هذا الزاحف.

لماذا يجب اختبار التخزين المؤقت في الحافة بعناية

يمكن لشبكة توصيل المحتوى (CDN) تقليل زمن الوصول إلى أول بايت عن طريق تقديم المحتوى أقرب إلى الطالب. ويمكنها أيضًا تقليل عدد الطلبات التي تصل إلى الخادم الأصلي. (web.dev)

اختبر ثلاث حالات تخزين مؤقت على الأقل:

1. ذاكرة تخزين مؤقت باردة (Cold cache) — يجب أن تتصل الحافة بالخادم الأصلي.
2. ذاكرة تخزين مؤقت دافئة (Warm cache) — تقدم الحافة الصفحة دون الاتصال بالخادم الأصلي.
3. ذاكرة تخزين مؤقت تمت إعادة التحقق منها (Revalidated cache) — تستخدم الحافة أو الزاحف قيمة ETag أو Last-Modified وتتلقى استجابة 304 Not Modified.

توصي Google بشكل خاص بالتخزين المؤقت لـ HTTP الفعال وتدعم استخدام استجابات 304 Not Modified لتقليل المعالجة غير الضرورية وعرض النطاق الترددي. (developers.google.com)

لا تسمح للتخزين المؤقت بتقديم محتوى قديم أو غير صحيح للزواحف. سجل:

• نجاح أو فشل التخزين المؤقت.
• عمر ذاكرة التخزين المؤقت.
• موقع الحافة.
• وقت استجابة الخادم الأصلي.
• إصدار المحتوى.
• رمز الحالة.
• رؤوس التحقق.

لماذا يجب ربط ضغط الصور بـ Largest Contentful Paint

توفر تنسيقات WebP و AVIF عمومًا ضغطًا أفضل من تنسيقات الصور القديمة. يمكن للصور الأصغر أن تقلل وقت النقل وقد تحسن الرسم الأكبر للمحتوى (Largest Contentful Paint) عندما تكون الصورة هي عنصر الرسم الأكبر للمحتوى. (web.dev)

يجب أن يستخدم الاختبار:

• نفس أبعاد الصورة.
• نفس هدف الجودة البصرية.
• صور srcset سريعة الاستجابة.
• تنسيقًا حديثًا مع خيار احتياطي مناسب.
• قيم width و height صريحة.
• عدم التحميل الكسول لصورة الرسم الأكبر للمحتوى.
• عنوان URL للصورة مرئيًا في HTML الأولي.

قد لا يؤدي ضغط الصور وحده إلى تحسين الرسم الأكبر للمحتوى إذا كان التأخير الحقيقي يأتي من جافاسكريبت أو اكتشاف الموارد المتأخر. تشير إرشادات أداء Google إلى أن تقليل وقت تنزيل الصور يمكن أن يحول التأخير ببساطة إلى جزء آخر من الصفحة إذا تم الكشف عن عنصر الرسم الأكبر للمحتوى متأخرًا. (web.dev)

3. قم بتشغيل الاختبار لفترة كافية

قد يفوت الاختبار القصير تأثيرات جدولة الزحف وتحديث الفهرس.

التصميم العملي هو:

• أسبوعان من القياس الأساسي.
• ستة إلى اثني عشر أسبوعًا من قياس المعالجة.
• فترة عكس أو تبديل نهائية إذا أمكن.

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

يجب تقييم بيانات مقاييس الويب الأساسية الميدانية على مدى فترة مناسبة. يستخدم تقرير تجربة مستخدم Chrome تجميعًا متجددًا لمدة 28 يومًا، لذلك فهو غير مصمم لإظهار التغييرات الفورية بعد النشر. (developer.chrome.com)

4. قياس كامل مجتمع الزواحف

لا تعامل جميع حركة المرور الآلية كمجموعة واحدة.

على الأقل، افصل:

زواحف البحث

• Googlebot.
• Bingbot.

زواحف بحث الذكاء الاصطناعي

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

برامج جلب المستخدمين المطلوبة

• Perplexity-User.
• Claude-User.
• برامج جلب مستخدمي ChatGPT حيث يمكن تحديدها.

زواحف التدريب

• GPTBot.
• ClaudeBot.
• عناصر تحكم Google-Extended.

لا ينبغي استخدام زواحف التدريب كوكيل لاستشهادات بحث الذكاء الاصطناعي. تميز Anthropic وOpenAI وGoogle بين الزواحف المستخدمة للتدريب أو البحث أو الاسترجاع الذي يطلبه المستخدم. وتذكر Google أيضًا أن Google-Extended لا يؤثر على تضمين Google Search أو ترتيبه. (help.openai.com)

وبالمثل، تميز Perplexity بين PerplexityBot، الذي يدعم فهرسة البحث، وPerplexity-User، الذي قد يسترد صفحة استجابة لطلب المستخدم. (docs.perplexity.ai)

تحقق من هوية الزاحف باستخدام نطاقات IP المنشورة أو DNS العكسي حيث يدعمها المزود. يمكن نسخ سلاسل وكلاء المستخدم (User-agent strings) بواسطة زواحف غير ذات صلة. تحذر Google على وجه التحديد من إمكانية تزوير سلاسل وكلاء المستخدم الخاصة بـ Googlebot. (developers.google.com)

المقاييس التي يجب جمعها

مقاييس الأداء

اجمع كلاً من البيانات المخبرية وبيانات المستخدم الحقيقية:

• زمن الوصول إلى أول بايت.
• أول رسم للمحتوى.
• الرسم الأكبر للمحتوى.
• تغيير التخطيط التراكمي.
• التفاعل مع الرسم التالي.
• إجمالي وزن الصفحة.
• حجم HTML الأولي.
• حجم نقل الصورة.
• عدد الطلبات.
• الوقت المستغرق في معالجة الخادم.
• الوقت المستغرق في انتظار مورد الرسم الأكبر للمحتوى.
• بروتوكول HTTP.
• حالة التخزين المؤقت.

توصي Google بزمن وصول تقريبي إلى أول بايت مستهدف يبلغ 800 مللي ثانية أو أقل، ولكن زمن الوصول إلى أول بايت ليس بحد ذاته مقياسًا أساسيًا لسلامة الويب. (web.dev)

عتبات مقاييس الويب الأساسية "الجيدة" الحالية عند المئين الخامس والسبعين هي:

• الرسم الأكبر للمحتوى: 2.5 ثانية أو أقل.
• تغيير التخطيط التراكمي: 0.1 أو أقل.
• التفاعل مع الرسم التالي: 200 مللي ثانية أو أقل. (web.dev)

مقاييس الزحف

لكل طلب زاحف تم التحقق منه، سجل:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

احسب:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

مقاييس استشهاد الذكاء الاصطناعي

استخدم مجموعة ثابتة من الاستعلامات عبر كل منصة. يجب أن تتضمن مجموعة الاستعلامات ما يلي:

• أسئلة واقعية مباشرة.
• أسئلة مقارنة.
• أسئلة "الأفضل" أو التوصيات.
• أسئلة حساسة للتحديث.
• أسئلة تكون فيها الصفحة المختبرة هي الإجابة الأقوى.
• أسئلة تكون فيها الصفحة المختبرة ذات صلة ولكنها ليست مهيمنة.

لكل استعلام، سجل:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

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

توفر أدوات مشرفي المواقع Bing Webmaster Tools الآن تقرير أداء الذكاء الاصطناعي الذي يوضح الصفحات المستشهد بها، واستعلامات التأسيس، واتجاهات الاستشهاد عبر تجارب الذكاء الاصطناعي المدعومة من Microsoft. تحذر Microsoft من أن البيانات مجمعة ومُعينة ومُلاحظة؛ ولا يمكنها إثبات أن تغييرًا معينًا في الصفحة تسبب في تغيير في الاستشهاد. (bing.com)

بدأت Google أيضًا في طرح تقارير أداء الذكاء الاصطناعي التوليدي المخصصة في Search Console في يونيو 2026. كانت التقارير متاحة في البداية لمجموعة فرعية فقط من مواقع الويب، لذلك قد يختلف الوصول. (developers.google.com)

التحليل الإحصائي

تكرار الزحف

استخدم نموذج عد مختلط التأثيرات، مثل نموذج السالب ذي الحدين:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

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

الاكتشاف والفهرسة

استخدم تحليل البقاء من أجل:

• الوقت من النشر إلى أول جلب.
• الوقت من النشر إلى أول فهرس.
• الوقت من التحديث إلى إعادة الزحف.

النتيجة الرئيسية ليست ببساطة ما إذا تم الزحف إلى صفحة في النهاية. بل هي ما إذا كانت المعالجة قللت من الوقت اللازم للعثور على الصفحة ومعالجتها.

اختيار استشهاد الذكاء الاصطناعي

استخدم نموذج لوجستي هرمي:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

قم بتشغيل نموذجين منفصلين:

1. نموذج الاسترجاع — هل تم استرجاع الصفحة أو عرضها كمرشح؟
2. نموذج الاستشهاد — إذا تم استرجاعها، هل تم الاستشهاد بالصفحة بشكل مرئي؟

هذا التمييز ضروري. إن تحسين الأداء الذي يزيد من الزحف ولكن لا يزيد من الاسترجاع ليس تأثير استشهاد بالذكاء الاصطناعي. إن تحسين الأداء الذي يزيد من الاسترجاع ولكن لا يزيد من الاستشهادات يشير إلى أن الصفحة يتم النظر فيها ولكنها تخسر أثناء اختيار المصدر.

النتائج المتوقعة

هذه فرضيات عمل، وليست نتائج تجريبية مزعومة.

الفرضية 1: سيكون لزمن الوصول إلى أول بايت أوضح تأثير على الزحف

توقع علاقة إيجابية بين انخفاض زمن الوصول إلى أول بايت وسعة الزحف عندما:

• يحتوي الموقع على العديد من الصفحات.
• تتغير الصفحات غالبًا.
• يكون الخادم الأصلي بطيئًا أو محملاً بشكل زائد.
• يعيد الموقع استجابات 5xx أو 429.
• يقضي الزاحف وقتًا طويلاً في انتظار الاستجابات.

توقع تأثيرًا ضعيفًا يمكن قياسه على موقع صغير ذي طلب زحف منخفض.

الفرضية 2: سيؤثر الرسم الأكبر للمحتوى من خلال العرض وتسليم الموارد

توقع أن يساعد الرسم الأكبر للمحتوى الأقل عندما:

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

توقع علاقة ضعيفة عندما يكون نص الصفحة المهم موجودًا بالفعل في HTML الأولي.

الفرضية 3: سيكون لتغيير التخطيط التراكمي تأثير مباشر قليل

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

إذا بدا أن تغيير التخطيط التراكمي يتنبأ بالاستشهاد، فابحث عما إذا كان يعمل كوكيل لـ:

• العرض من جانب العميل.
• إدراج المحتوى المتأخر.
• إعلانات غير مستقرة.
• نص مخفي أو متأخر.
• HTML ضعيف الهيكل.

الفرضية 4: السرعة وحدها لن تنتج المزيد من استشهادات الذكاء الاصطناعي

من المرجح أن تظل أقوى المتنبئات باختيار الاستشهاد هي:

• الصلة بالاستعلام.
• جودة المحتوى.
• الإجابات الواضحة.
• الحداثة.
• السلطة والثقة.
• أهلية فهرس البحث.
• ترتيب الاسترجاع.
• ما إذا كانت الصفحة تدعم بشكل مباشر الادعاء المقدم.

تؤكد إرشادات Google على المحتوى المفيد والموثوق والموجه للأشخاص وتقول إن ميزات بحث الذكاء الاصطناعي تستند إلى أنظمة البحث والفهرسة الحالية. (developers.google.com)

ميزانية أداء مضبوطة لاسترجاع الذكاء الاصطناعي

فيما يلي ميزانية تشغيل مقترحة. وهي ليست صيغة ترتيب ذكاء اصطناعي منشورة.

تشير وثائق Google الحالية إلى أن Googlebot يجلب أول 2 ميجابايت من ملف مدعوم ويجلب النصوص البرمجية وأوراق الأنماط الخارجية بشكل منفصل. كما توصي بوضع البيانات الوصفية المهمة والبيانات المنظمة في وقت مبكر من HTML. (developers.google.com)

توصيات التنفيذ

HTTP/3

استخدم HTTP/3 عندما يكون مدعومًا من قبل مزود الاستضافة وشبكة توصيل المحتوى.

قِس:

• معدل التفاوض على HTTP/3.
• معدل العودة إلى HTTP/2.
• وقت إعداد الاتصال.
• زمن الوصول إلى أول بايت.
• الأداء حسب المنطقة الجغرافية.
• الأداء حسب الزاحف.

لا تتعامل مع HTTP/3 على أنه تحسين مضمون للبحث أو الذكاء الاصطناعي. إنه تحسين نقل قد يساعد فقط العملاء الذين يستخدمونه.

التخزين المؤقت في حافة شبكة توصيل المحتوى (CDN Edge Caching)

للصفحات العامة غير المخصصة:

• ضع قواعد Cache-Control واضحة.
• استخدم التخزين المؤقت طويل الأمد للأصول الثابتة المنسوخة.
• استخدم التخزين المؤقت القصير ولكن المفيد لـ HTML المحدثة بشكل متكرر.
• تجنب تجزئة ذاكرة التخزين المؤقت من معلمات الاستعلام غير الضرورية.
• حافظ على عناوين URL الكنسية.
• دعم ETag و Last-Modified.
• اختبر حالات ذاكرة التخزين المؤقت الباردة، الدافئة، والتي تم إعادة التحقق منها.
• تأكد من أن طلبات الزواحف تتلقى نفس المحتوى المهم الذي تتلقاه طلبات البشر.

يجب أن تقلل شبكة توصيل المحتوى من الكمون دون إنشاء إصدارات صفحات قديمة أو غير متسقة أو خاصة بالبوتات.

ضغط الصور

للصور:

• استخدم AVIF أو WebP عندما تكون الجودة المرئية مقبولة.
• وفر أحجام صور متجاوبة.
• لا تقدم صورة بحجم سطح المكتب لشاشة جوال صغيرة.
• لا تقم بالتحميل الكسول لصورة الرسم الأكبر للمحتوى.
• قم بتضمين أبعاد الصورة.
• ضع صورة الرسم الأكبر للمحتوى في HTML الأولي.
• استخدم fetchpriority="high" فقط عندما يكون ذلك مناسبًا.
• حافظ على التفسيرات المهمة في النص بدلاً من تضمينها فقط داخل الصور.

يكون ضغط الصور ذا قيمة أكبر عندما تكون الصورة هي عنصر الرسم الأكبر للمحتوى. لن يصلح صفحة يكون تأخيرها الرئيسي ناتجًا عن عرض الخادم أو تنفيذ جافاسكريبت. (web.dev)

استقرار التخطيط

لتقليل تغيير التخطيط التراكمي:

• ضع سمات العرض والارتفاع على الصور.
• احجز مساحة للإعلانات.
• احجز مساحة للفيديو المضمن والمحتوى الاجتماعي.
• تجنب إدراج اللافتات فوق النص الموجود.
• استخدم استراتيجيات تحميل خطوط مستقرة.
• تجنب استبدال كتل كبيرة من المحتوى الذي تم عرضه من الخادم بعد تحميل الصفحة.

تحسن هذه التغييرات تجربة المستخدم حتى لو لم يكن لها تأثير قابل للقياس على الزحف أو الاستشهادات. (web.dev)

الأدوات والمراقبة

أدوات الأداء

استخدم:

• تقرير تجربة مستخدم Chrome (Chrome User Experience Report) لمقاييس الويب الأساسية للمستخدم الحقيقي.
• واجهة برمجة تطبيقات تقرير تجربة مستخدم Chrome (Chrome User Experience Report application programming interface) لجمع البيانات الميدانية الآلي.
• PageSpeed Insights لعمليات التدقيق المخبرية والبيانات الميدانية.
• Lighthouse لاختبارات معملية قابلة للتكرار.
• Lighthouse Continuous Integration لميزانيات أداء طلبات السحب.
• WebPageTest لاختبارات متعددة المواقع، حالات ذاكرة التخزين المؤقت، ومقارنات البروتوكولات.
• Chrome DevTools لتصحيح أخطاء الرسم الأكبر للمحتوى وتغيير التخطيط.
• مكتبة web-vitals JavaScript لمراقبة المستخدم الحقيقي.

توفر واجهة برمجة تطبيقات تقرير تجربة مستخدم Chrome بيانات حقلية مجمعة على مستوى الصفحة والمصدر، بما في ذلك الرسم الأكبر للمحتوى، وتغيير التخطيط التراكمي، والتفاعل مع الرسم التالي، ووقت الوصول التجريبي إلى أول بايت. (developer.chrome.com)

يمكن لـ Lighthouse Continuous Integration تشغيل فحوصات الأداء على كل تغيير في الكود وإفشال البناء عندما تتجاوز الميزانيات. (github.com)

مراقبة الزواحف

استخدم سجلات الخادم، سجلات الحافة، ومجموعة صغيرة من الفحوصات الاصطناعية.

مثال على الفحص:

bash curl --http3 -sS -o /dev/null -D - \ -w 'status=%{http_code}
http_version=%{http_version}
namelookup=%{time_namelookup}
connect=%{time_connect}
starttransfer=%{time_starttransfer}
total=%{time_total}
size=%{size_download}
' \ -A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \ https://example.com/page

قم بتشغيل نفس الاختبار مع:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• وكيل مستخدم متصفح عادي.

يجب أن يتحقق الاختبار مما يلي:

• رمز الحالة.
• إذن الروبوتات.
• رؤوس الاستجابة.
• محتوى HTML.
• إصدار HTTP.
• حالة ذاكرة التخزين المؤقت.
• وقت الاستجابة.
• ما إذا كان النص المهم موجودًا بدون جافاسكريبت.

مراقبة البحث والفهرسة

استخدم:

• إحصائيات زحف Google Search Console.
• تقارير فهرسة صفحات Google Search Console.
• فحص عناوين URL في Google Search Console.
• بيانات خريطة الموقع في Google Search Console.
• تقارير الذكاء الاصطناعي التوليدي في Google Search Console عند توفرها.
• طلبات زحف Bing Webmaster Tools والصفحات المفهرسة.
• أداء الذكاء الاصطناعي في Bing Webmaster Tools.
• فحوصات يومية لخرائط المواقع و lastmod.

يمكن لواجهة برمجة تطبيقات Search Console استرداد بيانات الأداء حسب الصفحة، الاستعلام، التاريخ، الجهاز، ومظهر البحث، وفقًا لقيود بياناتها. (developers.google.com)

مراقبة الاستشهادات

أنشئ لوحة استشهادات تحتوي على 50 إلى 200 استعلام ثابت لكل موضوع. قم بتشغيل اللوحة بجدول زمني ثابت وسجل:

• ما إذا كانت المنصة قد بحثت.
• المصادر التي ظهرت.
• ما إذا كان عنوان URL المختبر قد تم الاستشهاد به.
• ترتيب الاستشهاد.
• تاريخ ووقت الإجابة.
• ما إذا كانت الصفحة قد تغيرت.
• ما إذا كان النموذج أو تجربة البحث قد تغيرت.

لا تقارن عدد الاستشهادات من أنظمة مختلفة كما لو كانت متساوية. تذكر Microsoft أن نشاط الاستشهاد ليس درجة تصنيف، أو درجة سلطة، أو مقياس حركة مرور، أو درجة جودة. (bing.com)

قواعد التنبيه

أنشئ تنبيهات لـ:

• ارتفاع زمن الوصول إلى أول بايت بأكثر من 25 بالمائة.
• تجاوز الرسم الأكبر للمحتوى 2.5 ثانية عند المئين الخامس والسبعين.
• تجاوز تغيير التخطيط التراكمي 0.1.
• زيادة مستمرة في استجابات 5xx أو 429.
• انخفاض في معدل نجاح الزاحف.
• تغيير في robots.txt.
• خطأ في خريطة الموقع.
• انخفاض مفاجئ في الصفحات المفهرسة.
• انخفاض مفاجئ في استشهادات الذكاء الاصطناعي عبر عدة منصات.
• تغيير في حجم الاستشهاد يؤثر على منصة واحدة فقط.

قد يكون انخفاض الاستشهاد الذي يؤثر على منصة واحدة ناتجًا عن تغيير في النموذج، أو الفهرس، أو الاستعلام، أو المنتج بدلاً من مشكلة في أداء الصفحة. تحذر Microsoft صراحةً من أن اتجاهات الاستشهاد هي ملاحظة ويمكن أن تتغير بسبب تحديثات المحتوى، وطلب المستخدم، وتغييرات النظام أو النموذج. (bing.com)

الخلاصة النهائية

الاستنتاج الأكثر قابلية للدفاع عنه هو:

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

السلسلة السببية المتوقعة هي:

text كمون أقل ← سعة خادم أفضل ← عدد أقل من عمليات الجلب الفاشلة أو المتأخرة ← اكتشاف ومعالجة أسرع ← فرصة محسنة للفهرسة والاسترجاع ← زيادة محتملة في الاستشهادات

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

بالنسبة لمعظم مواقع الويب، فإن استراتيجية الأداء الصحيحة ليست "التحسين لاستشهادات الذكاء الاصطناعي" بشكل منفصل. بل هي:

1. الحفاظ على المحتوى المهم متاحًا في HTML الأولي.
2. الحفاظ على زمن الوصول إلى أول بايت مستقرًا.
3. استخدام التخزين المؤقت في الحافة للمحتوى العام.
4. ضغط الصور المهمة وتحديد أولوياتها.
5. منع تغييرات التخطيط.
6. إرجاع رموز حالة موثوقة.
7. الحفاظ على خرائط المواقع والروابط الداخلية حديثة.
8. السماح لزواحف البحث الصحيحة.
9. قياس الزحف، والفهرسة، والاسترجاع، والاستشهاد كمراحل منفصلة.

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