الطلبات الشرطية: ETag وIf-Modified-Since و304 Not Modified

الخلاصة — الطلب الشرطي هو أن يسأل Googlebot خادمك «هل تغيرت هذه الصفحة منذ آخر مرة جلبتها؟» قبل تنزيلها من جديد. إذا كانت الإجابة لا، يعيد الخادم استجابة صغيرة من نوع 304 Not Modified بلا صفحة، ويعيد الزاحف استخدام النسخة الموجودة لديه. يقلل ذلك العمل على كلا الطرفين، لكنه يفيد بصورة ملموسة في المواقع الكبيرة، ولا يرفع ترتيبك.

ما الطلب الشرطي؟

عندما يريد Googlebot صفحة، ينزّلها كاملة في المعتاد. أما الطلب الشرطي فأذكى: يقول الزاحف «لا ترسل الصفحة إلا إذا كانت مختلفة فعلاً عما كانت عليه في زيارتي السابقة».

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

• تاريخ — «عندما جلبت الصفحة سابقاً، أخبرتني أنها عُدلت آخر مرة في تاريخ معين. هل يوجد شيء أحدث؟»
• بصمة — «أعطيتني سابقاً معرّفاً لهذه الصفحة (ETag). هل ما زال المعرّف نفسه؟»

إذا لم يتغير شيء، يرد خادمك بـ 304 Not Modified. لا تتضمن هذه الاستجابة صفحة؛ إنها رسالة قصيرة تعني «كما كانت». عندئذ يعيد Googlebot استخدام النسخة التي حفظها بدلاً من تنزيل كل شيء مرة أخرى.

أما إذا تغير شيء، فيرسل الخادم الصفحة كاملة كالمعتاد ضمن استجابة 200 OK، ويأخذ الزاحف النسخة الجديدة.

لماذا يهم ذلك؟

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

هذه هي الفائدة كلها: الكفاءة. وهي جزء مما يسمى ميزانية الزحف، أي مقدار الزحف الذي يرغب محرك البحث في تنفيذه على موقعك.

التحفظ الصريح

هناك نقطتان ينبغي معرفتهما قبل الحماس:

1. يهم ذلك أساساً المواقع الكبيرة. في الموقع الصغير تكون الوفورات محدودة، وغالباً لا تستحق عناء الإعداد. وكما كتبت سابقاً، فإن فرصة التخزين المؤقت التي تتيحها استجابة 304 للمواقع الصغيرة “not that crucial” (ترجمة) «ليست بالغة الأهمية».
2. لن يحسن ترتيبك. زيادة كفاءة الزحف لا ترفع موقعك في النتائج؛ إنها تساعد المواقع الكبيرة فقط على زحف صفحاتها الجديدة والمتغيرة بسرعة أكبر قليلاً.

هل تريد معرفة الترويسات الدقيقة، وما صرحت Google بأنها تدعمه، والطرق التي تعطل بها المواقع هذه الآلية خفية، والفرق بينها وبين معدل الزحف وتكراره؟ انتقل إلى تبويب متقدم.

الخلاصة — تتيح الطلبات الشرطية لـ Googlebot التحقق من نسخة مخزنة مؤقتاً بدلاً من تنزيلها من جديد. يرسل If-Modified-Since للتحقق مقابل ترويسة Last-Modified و/أو If-None-Match للتحقق مقابل ETag؛ وإذا لم يتغير شيء، يعيد الخادم 304 Not Modified بلا متن، ويستخدم الزاحف نسخته الحالية، أي نحو 1 KB بدلاً من 100 KB أو أكثر للصفحة الكاملة. تكون الأولوية لـ ETag عند وجود الاثنين؛ توصي Google به لتجنب مشكلات تنسيق التاريخ، لكنها تنصح بضبط الاثنين. لا ترسل Google الترويسات في كل عملية زحف، ويعتمد ذلك على حالة الاستخدام، ويكون AdsBot أرجح في إرسالها. ويمكنك استباقياً إرسال 304 حتى بلا ترويسة شرطية، كما أن 304 لا تجمد إشارات الفهرسة. تعطلها ثلاثة أخطاء: إعادة 200 دائماً، أو ETag متقلب بسبب الطوابع الزمنية أو الرموز الخاصة بكل طلب أو اختلاف عقد CDN، أو Last-Modified لا يعكس التغييرات الحقيقية. إنها وسيلة لكفاءة الزحف في المواقع الكبيرة، وليست عامل ترتيب، وتختلف عن معدل الزحف وتكراره وميزانيته.

الآلية بدقة

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

يجري التدفق خطوة بخطوة هكذا:

1. في أول زحف، يعيد الخادم الصفحة مع 200 OK وتاريخ Last-Modified و/أو بصمة ETag.
2. في زحف لاحق، قد يرسل Googlebot ترويسة If-Modified-Since مكرراً التاريخ الذي رآه، و/أو If-None-Match مكرراً قيمة ETag.
3. يفحصهما الخادم. إذا لم يتغير شيء ذي صلة، يعيد 304 Not Modified بلا متن استجابة؛ أي الحالة والترويسات فقط.
4. يعيد Googlebot استخدام النسخة التي زحف إليها سابقاً. وإذا تغير المحتوى، يعيد الخادم 200 OK مع المتن الكامل.

توثق Google هذه المصافحة بصياغة تكاد تكون حرفية: “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (ترجمة) «ترسل برامج زحف Google التي تدعم التخزين المؤقت قيمة ETag المعادة من زحف سابق لعنوان URL في ترويسة If-None-Match. وإذا طابقت القيمة التي أرسلها الزاحف القيمة الحالية التي أنشأها الخادم، فينبغي أن يعيد الخادم حالة HTTP 304 (غير معدل) بلا متن HTTP».

ETag مقابل Last-Modified — ولماذا تفضل Google الأول

كلا أداتي التحقق مدعومتان. تنص وثائق زحف Google بوضوح: “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (ترجمة) «تدعم بنية زحف Google التخزين المؤقت الاستدلالي لـ HTTP كما يعرّفه معيار التخزين المؤقت، وتحديداً عبر ترويسة الاستجابة ETag وترويسة الطلب If-None-Match، وترويسة الاستجابة Last-Modified وترويسة الطلب If-Modified-Since».

عند وجود الاثنين، تكون الأولوية لـ ETag: “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (ترجمة) «إذا وُجد حقلا ترويسة الاستجابة ETag وLast-Modified معاً في استجابة HTTP، تستخدم برامج زحف Google قيمة ETag كما يقتضي معيار HTTP». ليست هذه خصوصية لدى Google؛ إنها قاعدة HTTP، وتتفق مع قاعدة الأولوية التي شرحتها في مدخل قاموس Ahrefs عن 304 Not Modified: عند استخدام If-None-Match وIf-Modified-Since معاً، تكون الأولوية لـ If-None-Match.

لماذا تفضل ETag؟ لأنها سلسلة مبهمة تمثل بصمة للمحتوى، فتتجنب مشكلات تحليل التاريخ التي تصيب Last-Modified. توصي Google: “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (ترجمة) «بالنسبة إلى برامج زحف Google تحديداً، نوصي باستخدام ETag بدلاً من ترويسة Last-Modified للإشارة إلى تفضيل التخزين المؤقت، لأن ETag لا تعاني مشكلات تنسيق التاريخ». وإذا استخدمت Last-Modified، فيجب تنسيق التاريخ وفق معيار HTTP (Weekday, DD Mon YYYY HH:MM:SS Timezone) وإلا فقد لا تحلله Google. ونصيحة Google العملية هي ضبط الاثنين على أي حال متى أمكن.

توجد إشارة إضافية أيضاً: Cache-Control: max-age. تقول Google إنها غير مطلوبة، لكن يمكنك ضبطها على عدد الثواني التي تتوقع بقاء المحتوى خلالها بلا تغيير لمساعدة برامج الزحف على تحديد موعد إعادة الزحف. لاحظ عدم التماثل: تراعي بنية الزحف لدى Google قيمة max-age كتلميح، لكنها لا تعامل توجيهات Cache-Control الأخرى كما يفعل المتصفح.

ما الذي تفعله 304 وما الذي لا تفعله؟

الفارق على الشبكة كبير. لا تحمل 304 متناً، ولذلك تبلغ، وفق مقارنة Gary Illyes التقريبية، نحو 1 KB بدلاً من 100 KB أو أكثر للصفحة الكاملة. كما أن إنشاءها أقل تكلفة، إذ لا يلزم عرض كامل أو استعلام قاعدة بيانات، ومعالجتها لدى Google أقل تكلفة، إذ لا يعاد تحليل المتن أو عرضه أو تشغيل مسار الفهرسة كاملاً عليه.

لكن كن دقيقاً بشأن ما لا تفعله 304: إنها لا تجمد إشارات ترتيبك. تذكر إرشادات Google لرموز الحالة أن مسار الفهرسة عند 304 “may recalculate signals for the URL,” (ترجمة) «قد يعيد حساب إشارات عنوان URL»، رغم أنه لم يجلب المتن مجدداً. تتجاوز 304 تنزيل المحتوى وإعادة معالجته، لا كل تقييم لاحق. لذلك لا توجد حيلة «أرسل 304 لتثبيت ترتيبي».

لا تسأل Google دائماً — وهذا طبيعي

تفوت معظم الشروحات تفصيلاً مهماً: لا يرسل Googlebot الترويسات الشرطية في كل طلب. تقول وثيقة أخطاء الزحف: “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (ترجمة) «تدعم Google عموماً ترويستي طلب HTTP If-Modified-Since وIf-None-Match للزحف. ولا ترسلهما برامج زحف Google في جميع محاولات الزحف؛ إذ يعتمد ذلك على حالة استخدام الطلب، فعلى سبيل المثال يكون AdsBot أرجح في ضبطهما».

لذلك، إذا نظرت في سجلاتك ورأيت أن Googlebot نادراً ما يرسل If-None-Match، فلا يعني ذلك أن إعدادك معطل؛ ربما لا تسأل Google في ذلك الزحف ببساطة. وتشير Google أيضاً إلى أن كل زاحف أو أداة جلب قد تستخدم التخزين المؤقت أو لا تستخدمه بحسب المنتج الذي تخدمه.

وفي الاتجاه الآخر، يمكنك إرسال 304 من دون تلقي ترويسة شرطية أصلاً. تقول Google: “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (ترجمة) «بصرف النظر عن ترويسات الطلب، يمكنك إرسال حالة HTTP 304 (غير معدل) من دون متن للاستجابة لأي طلب من Googlebot إذا لم يتغير المحتوى منذ آخر زيارة للعنوان. سيوفر ذلك وقت معالجة الخادم وموارده، وقد يحسن كفاءة الزحف بصورة غير مباشرة». هذه تقنية متقدمة عند CDN أو الحافة، وخطيرة إذا أخطأت؛ لأن إرسال 304 لمحتوى تغير فعلاً هو تحديداً فشل «أدوات التحقق تكذب». عاملها كتحسين حافة، لا كاختصار لادعاء الثبات.

لماذا يهم ذلك لميزانية الزحف؟

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

أما الجزء الصريح المحبط قليلاً، فهو أن Google تطلب زيادة التبني، لا تبلغ بأن الجميع يطبقه. ذكر Illyes أن حصة عمليات جلب Googlebot القابلة للتخزين المؤقت انخفضت خلال العقد الماضي من نحو 0,026 % إلى 0,017 %، رغم نمو الويب. أي أن هذه وسيلة قليلة الاستخدام، وأن عنوان قسم منشور «Crawling December» يكاد يكون رجاءً حرفياً: “Allow us to cache, pretty please.” (ترجمة) «اسمحوا لنا بالتخزين المؤقت، من فضلكم». معظم المواقع غير مهيأة لذلك ببساطة.

أخطاء الإعداد الشائعة التي تهزم الطلبات الشرطية

لا يعني ضبط أداة تحقق أنك تستفيد منها. تكسر المواقع هذه الآلية خفية بثلاث طرق — أو أربع:

1. إعادة 200 دائماً مع متن كامل

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

2. تغيّر ETag في كل طلب

هذا أخبث لأنه يبدو صحيحاً. إذا حُسبت ETag من عنصر متقلب، كطابع زمني مضمّن أو رمز خاص بالطلب أو الجلسة أو معرّف طلب أو ناتج بناء يتضمن وقت البناء، تحصل كل استجابة على ETag «جديدة» رغم تطابق المحتوى الظاهر. لا تطابق If-None-Match أبداً، فلا يجد الخادم أساساً لإعادة 304. الحل: اشتق ETag من تجزئة متن الاستجابة الفعلي أو معرّف إصدار محتوى ثابت، لا من شيء يتغير مع كل طلب.

3. اختلاف عقد CDN أو المجموعة

خطأ قريب: تنشئ عقد الأصل المختلفة قيماً ضعيفة مختلفة لـ ETag لمحتوى متطابق. لا يرى CDN أو الزاحف المتنقل بين العقد قيمة ثابتة، ويواصل إعادة التحقق من دون الوصول إلى 304 صحيحة. الحل: أنشئ ETag حتمياً من المحتوى، لا من حالة المثيل، أو وحّد إنشاءها عبر المجموعة.

4. قيمة Last-Modified لا تعكس التغييرات الحقيقية

إذا وُسمت Last-Modified بوقت «الآن» عند كل عرض، أو تغيرت بسبب تعديل تافه مثل سنة حقوق نشر تتحدث تلقائياً في التذييل، فإنها إما تطلق عمليات زحف كاملة بلا داعٍ لأن التاريخ يبدو جديداً دائماً، أو إذا كانت قديمة أو متلاعباً بها تضعف ثقة Google في الإشارة. هذا مبدأ الصدق نفسه الذي تطبقه Google على قيمة lastmod في خريطة الموقع: لا تستخدمها إلا إذا كانت تعكس تغييراً مهماً يمكن التحقق منه. يشرح مقال تكرار الزحف منطق lastmod، وينطبق الانضباط نفسه على ترويسة HTTP Last-Modified.

حالة Illyes الطرفية: عندما تثبت 304 صفحة معطلة

تستحق تنبيهاً مستقلاً لأنها مناقضة للحدس ولا يغطيها أحد تقريباً. وصف Illyes كيف يمكن أن تأتي 304 “backfire spectacularly” (ترجمة) «بنتيجة عكسية مذهلة»: يقدم خلل في الخادم صفحة فارغة معطلة ضمن 200؛ يعاملها الزاحف كخطأ عابر ويحدد إعادة زحف للتحقق؛ ثم تبلغ الصفحة التي ما زالت معطلة، وبصورة صحيحة، عن 304 «لم تتغير»؛ فيستنتج الزاحف أن حالة الخطأ هي المحتوى الدائم «الحقيقي» ويقلل مرات إعادة الفحص. ينتهي تسلسله بأن الزاحف “learn[ing] the error is persistable” (ترجمة) «يتعلم أن الخطأ قابل للاستمرار». وتحفظه: هل يحدث ذلك؟ نعم. كثيراً؟ قطعاً لا؛ “but it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (ترجمة) «لكن يجدر الاحتفاظ به في مكان عميق من ذهنك لأن تصحيحه كابوس مطلق». الدرس: قد ترسخ الطلبات الشرطية خطأً إذا كان توليد المحتوى معطلاً، فلا تضفها فوق أصل غير مستقر.

كيف يتعامل Bing معها؟

ليست هذه ميزة خاصة بـ Google، بل يمكن القول إن دعم Bing أقدم وأوضح. أعلن Bing، عندما كان Live Search، في 2008 عن طلب GET شرطي متوافق مع RFC 2616: إنه “generally will not download the page unless it has changed since the last time it crawled it” (ترجمة) «لن ينزّل الصفحة عموماً إلا إذا تغيرت منذ آخر مرة زحف إليها»، ويرسل If-Modified-Since مع وقت آخر تنزيل، وعند توافرها If-None-Match مع ETag. واليوم يضم Bing ذلك إلى مقياس مسمى قابل للتتبع هو كفاءة الزحف، ويعرّفه Fabrice Canel بأنه “how often we crawl and discover new and fresh content per page crawled.” (ترجمة) «معدل زحفنا واكتشافنا لمحتوى جديد وحديث لكل صفحة نزحف إليها». وتخفض عمليات إعادة الزحف غير الضرورية إلى المحتوى الثابت تلك الدرجة مباشرة. لذا تخدم أدوات التحقق نفسها المحركين، لكن Bing يمنح المفهوم لوحة نتائج.

هل يؤثر ذلك في الترتيب؟

لا. حافظ على الانضباط نفسه في مقالي معدل الزحف وميزانيته: الطلبات الشرطية وسيلة لكفاءة الزحف والموارد، وليست عامل ترتيب. لا يربط مصدر رسمي ETag أو If-Modified-Since أو 304 بالترتيب. الفائدة غير المباشرة هي أن المواقع الكبيرة أو كثيرة التحديث قد تزحف صفحاتها الجديدة والمتغيرة وتفهرس أسرع؛ لكن زيادة كفاءة الزحف ليست في ذاتها إشارة ترتيب.

كيف تتحقق من عملها؟

الحقيقة المرجعية في سجلات الخادم. ابحث عن أمرين: إرسال Googlebot ترويستي الطلب If-None-Match وIf-Modified-Since، وإعادة الخادم استجابات 304 إليه. البيانات الواقعية قليلة، وهذا ما يجعل دراسة سجلات الخادم لدى Tame the Bots التي أعدها Dave Smart قيّمة. راقب حركة Googlebot المتحقق منها، ووجد أن نحو 1,3 % فقط من الطلبات حصلت على 304، بينما كان معظمها 200، وأن طلبات If-None-Match تجمعت عندما طُلب عنوان URL مرة أخرى بعد وقت قصير من جلب سابق. تتفق خلاصته مع الإرشادات: نادرة في المواقع الصغيرة، لكنها قد تحقق “significant savings” (ترجمة) «وفورات كبيرة» في المواقع كثيفة الزحف. لا تتوقع معدل 304 مرتفعاً في موقع صغير؛ وتوقع أن يهم عند التوسع.

الطلبات الشرطية مقابل معدل الزحف وتكراره وميزانيته

لتمييز أفراد عائلة ميزانية الزحف:

• معدل الزحف — مدى سرعة جلب Googlebot، أي جانب العرض الذي تقيده صحة الخادم.
• تكرار الزحف — مدى تكرار إعادة جلب عنوان URL معروف، بحسب الشعبية وقدم النسخة.
• ميزانية الزحف — نطاق الطلب والسعة: مجموعة عناوين URL التي يستطيع Google الزحف إليها ويريد ذلك.
• الطلبات الشرطية — مدى قلة تكلفة الإجابة عن كل إعادة زحف. لا تغير سرعة الزحف أو تكراره؛ بل تجعل زيارة كل صفحة ثابتة شبه مجانية، فتمنع هدر الميزانية على محتوى مطابق.

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

خلاصة مكثفة للنسخة المتقدمة:

• الطلبات الشرطية = «هل تغير هذا؟» يرسل Googlebot If-Modified-Since للتحقق مقابل Last-Modified و/أو If-None-Match للتحقق مقابل ETag. إذا لم يتغير المحتوى، يعيد الخادم 304 Not Modified بلا متن ويستخدم الزاحف نسخته.
• تكون الأولوية لـ ETag عند وجود الاثنين؛ توصي Google بـ ETag لتجنب مشكلات تنسيق التاريخ، لكنها تنصح بضبط الاثنين. وCache-Control: max-age تلميح إضافي اختياري لتوقيت إعادة الزحف.
• تبلغ 304 نحو 1 KB بدلاً من 100 KB أو أكثر وتتجاوز إعادة التنزيل والمعالجة، لكنها لا تجمد إشارات الفهرسة؛ فقد تعيد Google حسابها.
• لا ترسل Google الترويسات دائماً؛ يعتمد ذلك على حالة الاستخدام ويكون AdsBot أرجح. ويمكنك إرسال 304 استباقياً حتى بلا ترويسة شرطية.
• تعطلها ثلاثة أخطاء: إعادة 200 مع متن كامل دائماً؛ وETag متقلب بسبب الطوابع الزمنية أو الرموز الخاصة بكل طلب أو اختلاف عقد CDN؛ وLast-Modified لا يتتبع التغييرات الحقيقية وفق مبدأ الصدق نفسه لقيمة lastmod.
• حالة طرفية: قد تجعل 304 فوق صفحة فارغة أو معطلة Googlebot يعامل الخطأ كأنه دائم، وفق Illyes.
• دعم Bing طلب GET الشرطي المتوافق مع RFC منذ 2008، ويتتبعه بوصفه «كفاءة الزحف».
• التبني منخفض ويتراجع، من نحو 0,026 % إلى 0,017 % من عمليات الجلب القابلة للتخزين خلال عقد؛ لذا فهي وسيلة قليلة الاستخدام للمواقع الكبيرة وليست عامل ترتيب.
• تحقق في سجلات الخادم من معدل 304 ووجود If-None-Match. تبين بيانات Tame the Bots أنها نادرة في المواقع الصغيرة ومهمة عند التوسع.

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

وثائق المصادر الأولية عن الطلبات الشرطية والتخزين المؤقت للزواحف.

Google

• أمور ينبغي معرفتها عن زحف Google للويب — عقد التخزين المؤقت الحالي: ETag وIf-None-Match، وLast-Modified وIf-Modified-Since، وأولوية ETag، وتلميح Cache-Control: max-age. (ملاحظة: نُقل المحتوى إلى هذا المسار من مسار /search/docs/... الأقدم؛ والإرشادات نفسها.)
• Crawling December: HTTP caching — منشور Gary Illyes في ديسمبر 2024 وراء تحديث الوثيقة، وعنوانه «اسمحوا لنا بالتخزين المؤقت، من فضلكم».
• استكشاف أخطاء زحف بحث Google — آلية If-Modified-Since و304، ومثال AdsBot، والسماح بإرسال 304 بلا ترويسة شرطية.
• أخطاء حالة HTTP والشبكة وDNS — تعامل Google مع 304؛ فقد يعاد حساب الإشارات بلا أثر سلبي في الفهرسة.
• تحسين ميزانية الزحف — المفهوم الأب ومن يحتاج فعلاً إلى الاهتمام به.
• إنشاء خريطة موقع وإرسالها — مبدأ الصدق في lastmod الموازي لانضباط ترويسة Last-Modified.

Bing / Microsoft

• الإعلان عن تحسينات زاحف Live Search — إعلان Bing الأصلي في 2008 عن GET الشرطي المتوافق مع RFC 2616، مع If-Modified-Since وIf-None-Match وETag.
• سلسلة bingbot: تعظيم كفاءة الزحف — مقياس Bing «كفاءة الزحف» ولماذا تقلله إعادة زحف المحتوى الثابت.
• Bing Webmaster Tools — Crawl Control — أداة جانب المعدل، مقابل الطلبات الشرطية بوصفها أداة كفاءة لكل زحف.

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

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

Google — ما المدعوم تحديداً

• “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (ترجمة) «تدعم بنية زحف Google التخزين المؤقت الاستدلالي لـ HTTP كما يعرّفه المعيار، وتحديداً عبر ترويسة الاستجابة ETag وترويسة الطلب If-None-Match، وترويسة الاستجابة Last-Modified وترويسة الطلب If-Modified-Since». — Google، أمور ينبغي معرفتها عن زحف Google للويب. انتقل إلى الاقتباس
• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (ترجمة) «إذا وُجد حقلا ترويسة الاستجابة ETag وLast-Modified معاً في استجابة HTTP، تستخدم برامج زحف Google قيمة ETag كما يقتضي معيار HTTP». انتقل إلى الاقتباس
• “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (ترجمة) «بالنسبة إلى برامج زحف Google تحديداً، نوصي باستخدام ETag بدلاً من ترويسة Last-Modified للإشارة إلى تفضيل التخزين المؤقت لأن ETag لا تعاني مشكلات تنسيق التاريخ». انتقل إلى الاقتباس
• “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (ترجمة) «ترسل برامج زحف Google التي تدعم التخزين المؤقت قيمة ETag المعادة من زحف سابق لعنوان URL في If-None-Match. وإذا طابقت القيمة المرسلة القيمة الحالية التي أنشأها الخادم، فينبغي أن يعيد حالة HTTP 304 (غير معدل) بلا متن HTTP». انتقل إلى الاقتباس

Google — متى ترسل الترويسات والسماح بـ 304 الاستباقية

• “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (ترجمة) «تدعم Google عموماً ترويستي طلب HTTP If-Modified-Since وIf-None-Match للزحف، لكنها لا ترسلهما في جميع محاولات الزحف؛ إذ يعتمد ذلك على حالة الاستخدام، ويكون AdsBot أرجح في ضبطهما». — Google، استكشاف أخطاء زحف بحث Google. انتقل إلى الاقتباس
• “If our crawlers send the If-Modified-Since header, the header’s value is the date and time the content was last crawled. Based on that value, the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time.” (ترجمة) «إذا أرسلت برامج زحفنا If-Modified-Since، تكون قيمتها تاريخ ووقت آخر زحف إلى المحتوى. وبناءً عليها قد يختار الخادم إعادة حالة HTTP 304 (غير معدل) بلا متن، وعندها تعيد Google استخدام نسخة المحتوى التي زحفت إليها آخر مرة». انتقل إلى الاقتباس
• “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (ترجمة) «بصرف النظر عن ترويسات الطلب، يمكنك إرسال حالة HTTP 304 (غير معدل) بلا متن لأي طلب Googlebot إذا لم يتغير المحتوى منذ آخر زيارة للعنوان. يوفر ذلك وقت معالجة الخادم وموارده، وقد يحسن كفاءة الزحف بصورة غير مباشرة». انتقل إلى الاقتباس

Gary Illyes، Google (LinkedIn — نمط فشل النتيجة العكسية لـ 304)

• “HTTP 304 (not modified) is super useful to signal crawlers that the content they’re accessing hasn’t changed since it was last crawled, but it can also backfire spectacularly.” (ترجمة) «تفيد HTTP 304 (غير معدل) جداً في إبلاغ الزواحف بأن المحتوى لم يتغير منذ آخر زحف، لكنها قد تأتي أيضاً بنتيجة عكسية مذهلة». اقرأ المنشور
• وعن مدى حدوث فخ الصفحة الفارغة ثم 304: “Does this ever happen? Yes. Often? Absolutely not. But it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (ترجمة) «هل يحدث هذا؟ نعم. كثيراً؟ قطعاً لا. لكن يجدر الاحتفاظ به في مكان عميق من ذهنك لأن تصحيحه كابوس مطلق». اقرأ المنشور

Bing (Live Search)، Fabrice Canel (إعلان GET الشرطي في 2008)

• “Live Search supports conditional get as defined by RFC 2616 (Section 14.25), and generally will not download the page unless it has changed since the last time it crawled it.” (ترجمة) «يدعم Live Search طلب GET الشرطي كما يعرّفه RFC 2616 (القسم 14.25)، ولن ينزّل الصفحة عموماً إلا إذا تغيرت منذ آخر مرة زحف إليها». انتقل إلى الاقتباس

هل يستحق تنفيذ الطلبات الشرطية العناء؟

لا يحتاج كل موقع إلى ذلك. حدد أولاً ما إذا كان يستحق وقتك قبل لمس إعدادات الخادم.

إجراء تشغيلي موحد: تنفيذ الطلبات الشرطية بصورة صحيحة

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

1. تأكد من أن المشكلة موجودة فعلاً. استخرج حركة Googlebot المتحقق منها من سجلات الخادم. إذا كانت معظم طلبات عناوين URL الثابتة تعيد 200 مع متن كامل، ولا تظهر ترويسات If-None-Match أو If-Modified-Since إلا قليلاً أو لا تظهر، فلديك فرصة للتحسين. وإذا كنت ترى 304 بالفعل للصفحات الثابتة، فتوقف؛ قد لا توجد فائدة كبيرة إضافية.

2. أنشئ ETag ثابتة قائمة على المحتوى. احسب ETag من تجزئة متن الاستجابة الفعلي أو معرّف إصدار محتوى ثابت. لا تشتقها من طابع زمني أو رمز خاص بالطلب أو الجلسة أو معرّف طلب أو أي شيء يختلف بين عقد الخادم. تحقق بطلب عنوان URL ثابت نفسه مرتين والتأكد من تطابق قيمة ETag في المرتين، وعبر جميع عقد CDN والأصل.

3. اضبط Last-Modified صادقة. اضبط Last-Modified على تاريخ ووقت آخر تغيير مهم في المحتوى، لا وقت العرض الحالي، ولا قيمة تتحرك لمجرد تغير سنة التذييل أو طابع زمني. نسقها وفق معيار HTTP (Weekday, DD Mon YYYY HH:MM:SS Timezone). وإذا أمكن، اضبط ETag و Last-Modified معاً؛ ستفضل Google ETag.

4. أعد 304 بصورة صحيحة. عندما تطابق If-None-Match الواردة قيمة ETag الحالية، أو لا يكون If-Modified-Since أقدم من Last-Modified، ولم يتغير شيء، فأعد 304 Not Modified من دون متن للاستجابة؛ أي الحالة والترويسات فقط. تستطيع معظم خوادم الويب والأطر فعل ذلك تلقائياً، لكن تحقق من أن وكيلاً أو CDN أمام الأصل لا يزيل الاستجابة.

5. اختياري: أضف تلميح Cache-Control max-age. اضبط Cache-Control: max-age=<seconds> على عدد الثواني التي تتوقع بقاء المحتوى خلالها بلا تغيير، بوصفه تلميحاً إضافياً لتوقيت إعادة الزحف. إنه تلميح لا ضمان.

6. تحقق في السجلات، ثم اترك الإعداد يعمل. أعد فحص السجلات بعد بضعة أسابيع. ينبغي أن ترى طلبات If-None-Match من Googlebot تقابلها 304 للصفحات الثابتة، و200 فقط عند تغير المحتوى فعلاً. لا تتوقع معدل 304 مرتفعاً في موقع صغير؛ توقع أثره عند التوسع.

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

خرافات وأخطاء ينبغي تجنبها

هذه المفاهيم الخاطئة المتكررة تسبب هدراً أو أعطالاً خفية:

• «يرسل Googlebot دائماً If-Modified-Since أو If-None-Match، فإذا لم أرهما في السجلات فخادمي معطل». خطأ. تقول Google صراحة إنها لا ترسل الترويسات في كل زحف؛ يعتمد ذلك على حالة الاستخدام، ويرسلها زاحف البحث الرئيسي بصورة غير ثابتة، بينما يُذكر AdsBot بوصفه أرجح. أظهرت بيانات Tame the Bots الواقعية أن أقل بكثير من 2 % من الطلبات تلقت 304 في الموقع المختبر.

• «تعني 304 أن Google لن تعيد تقييم ترتيبي أو إشاراتي». خطأ. تذكر وثائق Google أن مسار الفهرسة قد يعيد حساب إشارات عنوان URL حتى مع 304؛ الذي يُتجاوز فقط هو تنزيل المحتوى وإعادة معالجته.

• «ضبط ETag يعني تلقائياً حصولي على 304». خطأ إذا كانت ETag متقلبة. فالقيمة المبنية على طابع زمني أو رمز خاص بكل طلب أو حالة كل عقدة تتغير في كل طلب، فلا تطابق If-None-Match أبداً. ويصعب تشخيصها أكثر لأنها تبدو مهيأة بصورة صحيحة عند النظرة الأولى.

• «يكفي وجود Last-Modified؛ يصلح أي تاريخ». خطأ. إذا لم تتتبع التغييرات الحقيقية، كأن تُضبط على «الآن» في كل عرض أو تتغير بسبب تعديل في التذييل، فإنها تطلق إعادة زحف مهدرة أو تضعف ثقة Google في الإشارة؛ وهو المبدأ نفسه الذي تذكره Google لقيمة lastmod في خريطة الموقع.

• «لا تكون 304 إلا إجابة تفاعلية لطلب GET شرطي». خطأ. تسمح Google صراحة للخوادم بإعادة 304 استباقياً بلا متن لأي طلب Googlebot عندما يعرف الخادم أن المحتوى لم يتغير.

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

• «يهم هذا مواقع المؤسسات العملاقة فقط». صحيح غالباً من حيث الإلحاح؛ تستهدف Google المواقع الكبيرة ذات المحتوى النادر التغيير، لكن الآلية وأخطاء الإعداد تنطبق على أي موقع. في الموقع الصغير لا يستحق الإعداد العناء غالباً.

افحص أدوات تحقق التخزين المؤقت لعنوان URL باستخدام curl

اعرف أدوات التحقق التي يرسلها خادمك وما إذا كان يعيد 304 عندما تكررها إليه.

1) اعرض ترويسات الاستجابة وابحث عن ETag وLast-Modified

curl -sI https://example.com/some-page | grep -iE 'etag|last-modified|cache-control'
# ETag: "a1b2c3d4e5"
# Last-Modified: Thu, 22 Jan 2026 01:28:49 GMT
# Cache-Control: max-age=94043

2) أرسل طلباً شرطياً باستخدام ETag؛ المطلوب استجابة 304

curl -sI https://example.com/some-page \
  -H 'If-None-Match: "a1b2c3d4e5"'
# HTTP/2 304        ← correct: server confirms nothing changed, sends no body
# HTTP/2 200        ← if you get this on an unchanged page, your validators aren't working

3) أرسل طلباً شرطياً باستخدام التاريخ بدلاً من ذلك

curl -sI https://example.com/some-page \
  -H 'If-Modified-Since: Thu, 22 Jan 2026 01:28:49 GMT'
# HTTP/2 304

اكتشف ETag المتقلبة

إذا أعاد عنوان URL الثابت نفسه قيمة ETag مختلفة في طلبين متتاليين، فهي متقلبة ومبنية على طابع زمني أو رمز، ولن تطابق If-None-Match أبداً:

# Request twice; the two ETag values should be IDENTICAL for an unchanged page
for i in 1 2; do curl -sI https://example.com/some-page | grep -i '^etag:'; done
# ETag: "a1b2c3d4e5"
# ETag: "a1b2c3d4e5"   ← good (stable)
# ETag: "9f8e7d6c5b"   ← BAD if different: your ETag changes every request

افحص استجابات 304 سريعاً في سجلات الوصول

تحقق من نشاط الطلبات الشرطية الحقيقي من Googlebot. عدّل مواضع الحقول وفق تنسيق سجلك؛ يفترض المثال أن حقل الحالة على نمط السجل المدمج:

# Count status codes returned to Googlebot
grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
#   4211 200
#     53 304        ← these are the conditional-request wins
#     12 301

# See which URLs are getting 304s
grep -i 'googlebot' access.log | awk '$9==304 {print $7}' | sort | uniq -c | sort -rn | head

(تحقق من أن الطلب يعود فعلاً إلى Googlebot بفحص DNS عكسي ثم أمامي قبل الوثوق بسلسلة وكيل المستخدم؛ حركة Googlebot المزيفة شائعة.)

فحص سريع في وحدة تحكم DevTools بالمتصفح

الصق المقطع في وحدة تحكم Chrome DevTools لقراءة أدوات التحقق التي تلقاها المتصفح للصفحة الحالية:

// Reads the ETag / Last-Modified the server sent for THIS page
fetch(location.href, { method: 'HEAD' }).then(r => {
  console.log('ETag:', r.headers.get('etag'));
  console.log('Last-Modified:', r.headers.get('last-modified'));
  console.log('Cache-Control:', r.headers.get('cache-control'));
});

إطار أداة التحقق ← الطلب ← الاستجابة

1. أداة التحقق: تقدم استجابة 200 الأولى ETag أو Last-Modified أو كليهما.
2. الطلب: يعيد جلب لاحق القيمة في If-None-Match أو If-Modified-Since.
3. الاستجابة: يعيد المحتوى الثابت 304 بلا متن؛ ويعيد المحتوى المتغير 200 مع المتن الجديد وأداة التحقق.
4. فحص الثبات: ينبغي أن تتغير أدوات التحقق عند تغير محتوى التمثيل، لا لأن الطلب أصاب خادماً آخر أو تضمن طابعاً زمنياً.

ورقة مرجعية لترويسات الطلب الشرطي

أدوات فحص أدوات التحقق

• تعرض أداة فحص ترويسات HTTP قيم ETag و Last-Modified وترويسات التخزين المؤقت وتغيرات الترويسات عبر عمليات إعادة التوجيه.
• تتيح لوحة Network في DevTools بالمتصفح فحص أدوات التحقق الأولية والترويسات الشرطية في طلب متكرر.
• curl أوضح اختبار قابل للتكرار: التقط أداة تحقق وأعد إرسالها وتأكد من أن الاستجابة الثابتة هي 304.
• يكشف تحليل سجلات الوصول ما إذا كانت طلبات الزواحف الشرطية تتلقى 304 فعلاً عند التوسع.

مقاييس سلامة الطلبات الشرطية

معدل الإصابات الشرطية

المقياس: الطلبات الشرطية المؤهلة التي تعيد 304. ما الذي يخبرك به: هل تمنع أدوات التحقق نقل متون لم تتغير. طريقة استخراجه: جمّع طلبات سجل الوصول التي تحمل If-None-Match أو If-Modified-Since بحسب حالة الاستجابة. المعيار أو النطاق الواقعي: أنشئ خط أساس بحسب القالب ووتيرة التغيير؛ ينبغي أن تختلف الصفحات كثيرة التحديث طبيعياً عن الأرشيفات الثابتة. الوتيرة: شهرياً، وبعد تغييرات التخزين المؤقت أو CDN.

البايتات التي وفرتها استجابات 304

المقياس: تقدير بايتات متن الاستجابة التي لم تُنقل. ما الذي يخبرك به: فائدة النطاق الترددي لا مجرد عدد الاستجابات. طريقة استخراجه: قارن كل عنوان URL أعاد 304 بأحدث حجم متن 200 في السجلات أو تصدير الزحف. المعيار أو النطاق الواقعي: قارن بالفترة السابقة للموقع نفسه؛ لا يوجد هدف عالمي صادق. الوتيرة: شهرياً.

عدم استقرار أدوات التحقق

المقياس: عناوين URL الثابتة التي تتغير قيمة ETag أو Last-Modified لديها بين الفحوص. ما الذي يخبرك به: هل يهزم الاختلاف بين الطلبات أو العقد إعادة التحقق. طريقة استخراجه: كرر طلبات الترويسات نفسها على عينة ثابتة. المعيار أو النطاق الواقعي: ينبغي أن تبقى أدوات التحقق ثابتة ما دام التمثيل لم يتغير. الوتيرة: بعد عمليات النشر أو تغييرات CDN أو موازن الحمل.

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

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

• ما استجابة 304 Not Modified؟ (قاموس Ahrefs لتحسين محركات البحث) — شرحي لتدفق الطلب الشرطي كاملاً، وقاعدة أولوية If-None-Match، ولماذا تكون فرصة 304 “not that crucial” (ترجمة) «غير بالغة الأهمية» للمواقع الصغيرة لكنها “great opportunity” (ترجمة) «فرصة رائعة» للمواقع الكبيرة.
• متى ينبغي القلق بشأن ميزانية الزحف؟ — المفهوم الأب: ماهية ميزانية الزحف، والطلب مقابل السعة، ومن يحتاج إلى الاهتمام قبل الانتقال إلى الطلبات الشرطية.
• ما Googlebot وكيف يعمل؟ — كيف يقرر Googlebot ما الذي يزحف إليه وبأي سرعة، وسياق المجدول.
• دليل المبتدئ إلى تحسين محركات البحث التقني — موضع كفاءة الزحف في الصورة الأكبر.

محاضراتي

• كيف يعمل البحث (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، بما في ذلك عوامل طلب الزحف التي تحدد ما يعاد جلبه. وينطبق تنبيهي المعتاد: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملاً أو دقيقاً بنسبة 100 %».

من أنحاء المجال

• Crawling December: HTTP caching (Google Search Central) — منشور Gary Illyes الذي يطلب من أصحاب المواقع تمكين التخزين المؤقت، ومصدر إحصائية تراجع التبني.
• هل يستخدم Googlebot ترويسات ETag؟ (Tame the Bots، بقلم Dave Smart) — دراسة نادرة لسجلات الخادم عن سلوك طلبات Googlebot الشرطية؛ فمعظم الشروحات المنافسة تعيد صياغة المواصفات بلا بيانات ملحوظة.
• Google توضح تعامل زواحفها مع ترويسات التحكم في التخزين المؤقت (Barry Schwartz، Search Engine Land) — تغطية تحديث وثائق ديسمبر 2024، مع إعادة الاقتباسات الأساسية عن ETag وLast-Modified حرفياً.
• إرشادات زواحف Google المحدثة توصي بـ ETag (Roger Montti، Search Engine Journal) — سبب تفضيل Google لـ ETag، والتنبيه إلى أن كل زاحف قد يستخدم التخزين المؤقت أو لا يستخدمه.
• الإعلان عن تحسينات زاحف Live Search (Fabrice Canel، Bing Webmaster Blog) — إعلان Bing الأصلي في 2008 عن طلب GET الشرطي المتوافق مع RFC 2616، مع نموذج طلب واستجابة.
• سلسلة bingbot: تعظيم كفاءة الزحف (Bing Webmaster Blog) — تصور Bing لكفاءة الزحف، حيث تخفض إعادة زحف المحتوى الثابت المقياس مباشرة.
• MDN: طلبات HTTP الشرطية (Mozilla) — مرجع محايد على مستوى المواصفات لأدوات التحقق وآلية 304.

اختبر نفسك: الطلبات الشرطية

خمسة أسئلة سريعة عن ETag وIf-Modified-Since و304 Not Modified. اختر إجابة لكل سؤال، ثم تحقق منها.

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