التحقق من آخر رأس تم تعديله. يعمل رأس Last-Modified على تسريع فهرسة الصفحات الجديدة في بعض الأحيان

توقيت غرينيتش. يتم التعبير عن تواريخ HTTP دائمًا بتوقيت غرينتش ، وليس بالتوقيت المحلي أبدًا.

أمثلة

تحديد

التوافق المتصفح

يتم إنشاء جدول التوافق في هذه الصفحة من البيانات المنظمة. إذا كنت ترغب في المساهمة في البيانات ، يرجى مراجعة https://github.com/mdn/browser-compat-data وإرسال طلب سحب إلينا.

تحديث بيانات التوافق على جيثب

هناك الكثير من الخرافات المختلفة في مجال تحسين محركات البحث (SEO). البعض منهم له أساس ، والذي لم يفهم أين. في هذه الملاحظة ، سننظر في أحدها - استخدام رأس الرد الأخير المعدل.

لقد صادفنا منذ فترة وثيقة بعنوان "إرشادات Ingate لاستوديوهات الويب على المواقع التي يتم الترويج لها". وكانت إحدى "التوصيات" على النحو التالي:

بعد إعادة التصميم أو تطوير موقع جديد ، يجب كتابة تاريخ آخر تعديل لصفحات الموقع (آخر تعديل)

لإضافة معلومات حول تاريخ آخر تعديل للصفحات إلى الموقع في PHP ، تحتاج إلى إدخال البرنامج النصي في بداية الكود المصدري لكل صفحة

header ("Last-Modified:". date ("D، d M Y H: i: s"، time ()). "GMT")؛
?>

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

ما هو آخر تعديل

خادم الويب ، عند نقل المعلومات إلى العميل (المتصفحات أو روبوت البحث) ، يبلغ عن الكثير من البيانات الإضافية. يمكن عرضها في وحدة تحكم المتصفح ، على سبيل المثال:

قم بتكوين الخادم لإصدار رؤوس استجابة صحيحة (على سبيل المثال ، إذا لم تكن الصفحة موجودة ، فأصدر خطأ 404 ، وإذا تم استلام طلب If-Modified-Since ، فأصدر الرمز 304 إذا لم تتغير الصفحة منذ التاريخ المحدد في الطلب).

يمكنك أيضًا معرفة أنه إذا لم يستجب الخادم بأي شكل من الأشكال لطلب GET المشروط ، فلا يختلف عن الطلب العادي. أي أن رأس Last-Modified مع الوقت الحالي ، وأيضًا التي تم تشكيلها بشكل غير صحيح (مرحبًا تكامل!) ليست ضرورية على الإطلاق!

إذن هل Last-Modified ضروري أم لا؟

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

ولكن غالبًا ما يكون من الصعب جدًا تنفيذ ذلك في CMS مكتمل. ربما سيتطلب هذا تغييرات كبيرة جدًا في رمز CMS نفسه.

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

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

بدلا من الاستنتاج

وهكذا ، اكتشفنا رأس Last-Modified. أولاً ، يجب أن تنقل معلومات حول تاريخ ووقت تعديل المستند بالفعل. ثانيًا ، يعد رد فعل الخادم على الطلب المشروط باستخدام رأس If-Modified-Since مهمًا للغاية.

حسنًا ، استمع بشكل أقل إلى مُحسّنات محرّكات البحث الذين لا يعرفون الأساسيات الأساسية للإنترنت.

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

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

استجابة الخادم الصحيحة

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

وبالتالي ، من خلال إعداد الاستجابات الصحيحة لخادمنا ، فإننا نقتل ما لا يقل عن خمسة طيور بحجر واحد:

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

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

كيفية تكوين 304 و 200 استجابات الخادم؟

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

لذلك ، نحتاج فقط إلى الاهتمام بالكود 304 ، لأن الخادم لن يرسله دون تدخلنا. للقيام بذلك ، سوف يساعدنا ، وكذلك العنوان آخر تعديلوطلب.

الألقاب آخر تعديل

آخر تعديلهو الرأس الذي نرسله مع PHP ، يحتوي هذا الرأس على الوقت المحدد الذي تم فيه آخر تعديل للصفحة (بالثواني). للقيام بذلك ، يتم استخدام المقياس المقبول عمومًا لقياس الوقت: طابع زمني يونكس.

طابع زمني يونكسهو عدد الثواني منذ بداية عهد يونكس: 1 يناير 1970. حتى كتابة هذه السطور ، الطابع الزمني لليونيكس هو 1370597447 ثانية ، وهو 06/07/2013 09:30:47 GMT (+00: 00).

وهذا يعني أن كل ما يتعين علينا القيام به هو مجرد إرسال رأس PHP مع التعليمات آخر تعديلوالتاريخ المطلوب:

Header ("Last-Modified:" .gmdate ("D، d M Y H: i: s"، $ last_modified_time). "GMT")؛

حيث يكون header بناءًا لإرسال رأس HTTP ، آخر تعديل- ما نرسله وبعد القولون مباشرة قيمته:

Gmdate ("D، d M Y H: i: s"، $ last_modified_time). "GMT".

آخر قيمة تم تعديلها هي الوظيفة gmdate ()الذي يحتوي على المتغير الذي اخترعته $ last_modified_time(يمكنك تسميتها أيا كان). في متغير $ last_modified_timeويحتوي على وقت التعديل الأخير في التنسيق طابع زمني يونكس، والوظيفة gmdate ()يخدمنا من أجل إحضار التاريخ بالشكل المناسب (توقيت غرينتش).

من أجل الوضوح ، إليك مثال لك: إذا كنا في وظيفة gmdate ()ضع القيمة 1365003142 ، ثم سيكون الناتج: الأربعاء، 03 أبريل 2013 03:32:22 م.

الآن وقد تعلمنا كيف تعمل العملية برمتها ، فقد يطرح السؤال التالي: "هل نحتاج إلى الإشارة يدويًا إلى وقت آخر تعديل لكل صفحة؟". الجواب: "نعم!" أنا شخصياً أفعل ذلك - يدويًا ، الخيار الأكثر موثوقية. ومع ذلك ، على وجه التحديد بالنسبة لهذه المدونة ، قمت بتقديم كل شيء ، على سبيل المثال ، إذا ظهر تعليق جديد على الصفحة ، ثم في المتغير $ last_modified_timeوقت تسجيل هذا التعليق ، يتم ذلك حتى تتمكن محركات البحث من فهرسة التعليقات الجديدة ومعرفة أن الموقع "مباشر". يختلف كل موقع عن الآخر وسيتعين عليك وضع خوارزمية خاصة بك لتحديد تاريخ آخر تعديل للصفحة ، أو تحديده يدويًا دائمًا.

مرة أخرى ، أؤكد أن الخوارزمية الخاصة بي هي كما يلي:

1) أشير إلى تاريخ إنشاء المادة يدويًا ، إذا قمت بتغيير شيء ما في المقالة (أخطاء إملائية أو إضافة) ، فقم بإدخال الوقت الجديد يدويًا لآخر تحديث.

2) إذا أضاف الزائر تعليقاً ، في المتغير $ last_modified_timeتلقائيًا ، دون علمي ، يتم إدخال الوقت الذي تم فيه إضافة التعليق ، حيث سيكون هذا في الواقع هو تاريخ آخر تعديل للصفحة.

ما لم أخذه بعين الاعتبار: في العمود الأيمن من الموقع لدي مقالات جديدة, مُستَحسَنو أعلى 10. يتغيرون باستمرار وفي نفس الوقت لجميع الصفحات. إذا قمت في كل مرة بتغيير العمود الأيمن من الموقع (تلقائيًا أو يدويًا - لا يهم) تاريخ آخر تعديل للصفحة ، فسيتم فقد النقطة الكاملة لهذا الإجراء. قررت أنه ينبغي تتبع هذه التغييرات وأخذها في الاعتبار عند التحديد $ last_modified_timeلا يستحق كل هذا العناء ، لأنها لا تفيد تحسين محركات البحث.

كما كتبت ، لا يمكنني أن أخبرك بالضبط عن كيفية أتمتة تاريخ آخر تعديل للصفحة ، لكنني سأخبرك كيف لا تفعل ذلك!

أخطاء عند تحديد تاريخ آخر تعديل

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

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

إنه مجرد مناهض لتحسين محركات البحث ، فكر بنفسك ، يأتي إلى صفحة محرك البحث الخاص بك ويظهر: "رائع! آخر مرة تم فيها تغيير الصفحة كانت الآن ، لذا خمنت متى ستأتي ، أيها الفصل! بعد يومين ، جاء إلى نفس الصفحة: "انظر ، لقد تغيرت مرة أخرى ، هذه صدفة ... انتظر ، لماذا لا أرى أي تغييرات؟ حسنًا ، سأعود مرة أخرى ". يأتي مرة أخرى: "حسنًا ، لا يا رفاق ، لم يعد هذا مضحكًا ، بالتأكيد لا يمكن الوثوق بك." هذه حكاية خرافية :)

وبعد ذلك يتساءل الناس لماذا النتائج في نتائج البحث ليست بالشكل الذي يرغبون فيه ، ولكن لأن المبتذلة تضيع في موقعك ثقة(يثق). تمامًا كما في المثل "عن الراعي والذئاب".

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

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

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

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

If (isset ($ _ SERVER ["HTTP_IF_MODIFIED_SINCE"]) && strtotime ($ _ SERVER ["HTTP_IF_MODIFIED_SINCE"])> = $ last_modified_time) (header ("HTTP / 1.1 304 Not Modified") ؛ die ؛) رأس ("Last-Modified") ؛ die ؛) : ".gmdate (" D، d M Y H: i: s "، $ last_modified_time)." GMT ")؛

لذلك ، في السطر الأول ، نتحقق من المساعدة فيما إذا كان طلب HTTP_IF_MODIFIED_SINCE قد وصل إلى خادمنا ، ونتحقق أيضًا على الفور من عدد الثواني في HTTP_IF_MODIFIED_SINCE الوارد أكبر من في $ last_modified_timeأم لا؟ إذا كان أكثر من ذلك ، فإن تاريخ آخر زيارة للعميل يكون متأخرًا عن تاريخ آخر تغيير للصفحة ، ومن هنا نستخلص استنتاجًا منطقيًا بحتًا مفاده أن الصفحة لم تتغير ، مما يعني أننا نرسل استجابة الخادم في السطر الثاني 304 غير معدلوالسطر الثالث نقتل (نوقف) تنفيذ جميع النصوص على الصفحة. بمعنى آخر ، نتوقف عن تنزيله.

إذا لم يرسل لنا العميل طلب HTTP_IF_MODIFIED_SINCE أو كانت زيارته الأخيرة قبل تاريخ آخر تعديل للصفحة ، فسنقوم (افتراضيًا) بإرجاع الكود 200 جيدوفي السطر الخامس نرسل له التاريخ الفعلي لتغيير الصفحة ، بدلاً من التاريخ الذي كان لديه.

حول IF_MODIFIED_SINCE وكيفية ترتيب الكود ، قال لك كل ما تحتاجه ، باستثناء ما تفعله وظيفة strtotime ():

Strtotime ($ _ SERVER ["HTTP_IF_MODIFIED_SINCE"])

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

وأخيرًا ، علينا فقط تمكين التخزين المؤقت ، ويتم ذلك باستخدام الأسطر التالية:

Header ("CacheControl: public") ؛ header ("Expires:". date ("r"، time () + 10800)) ؛

حيث أن الرقم 10800 هو الوقت (بالثواني) الذي نريد تخزين الصفحة فيه مؤقتًا ، أي في هذا المثال لمدة 3 ساعات.

وكالعادة ، لمن لا يفهم شيئًا ، أنشر كل شيء بالكامل ، كما هو مرتب على مدونتي:

أعتقد أنك ربما لاحظت أن هذه القصة بأكملها مع Last-modified هي تماثل للعلامة في -. لذا فإن Lastmod ذات طبيعة مألوفة واستشارية ، ولن يجادل أحد في إجابات الخادم الخاص بك. بطبيعة الحال ، ليس من غير المألوف أن يكون النموذج الأخير في خريطة الموقع مختلفًا عن رأس LastModified ، ولكن من الآن فصاعدًا ، يجب أن تكون هي نفسها بالنسبة لك! بعد كل شيء ، لقد درسنا الآن نوعًا من العلوم ، وليس لكي نصبح مثل مشرفي المواقع المؤسفين الذين لم يتقدموا إلى أبعد من ملف sitemap.xml.

أنا شخصياً لا أستخدم علامة lastmod على الإطلاق في ملفات Sitemap الخاصة بي في الوقت الحالي ، وربما سأعيد النظر في الأمر لاحقًا ، لكن في الوقت الحالي لا أرى الهدف من أن أكون دقيقًا للغاية مع العناوين المناسبة آخر تعديل :)

وأخيرًا ، تحقق من صحتها آخر تعديلويمكنك مع هذه الخدمة: انقر.

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