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

هذا الدليل مخصص لمن يدير مستندًا عامًا ويحتاج إلى أن يتلقى القراء محتواه المعدّل عبر عنوان URL الحالي. تستخدم خطوات سطح المكتب Chrome على macOS. ويقدّم «دليل أشكال الورق» الافتراضي، الذي يتغير من «المراجعة A: دوائر» إلى «المراجعة B: دوائر ومربعات»، طريقة بسيطة للتمييز بين الإصدارات خلال سير العمل.

لماذا لا يؤدي تعديل المصدر إلى تحديث كل صفحة مخزنة مؤقتًا؟

يزيل إبطال HTTP استجابة مخزنة أو يجعل التحقق إلزاميًا قبل إعادة استخدامها. يفرض RFC 9111 على ذاكرة التخزين المؤقت إبطال عنوان URI المستهدف بعد نجاح طلب يغيّر الحالة ويمر عبرها، لكنه ينص صراحةً على أن ذلك لا يبطل النسخ على مستوى العالم. لذا يجب أن يراعي سير النشر ذاكرات التخزين المؤقت التي لا يمر بها طلب التعديل. RFC 9111: إبطال الاستجابات المخزنة.

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

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

ما تلاحظه ما الذي ينبغي التحقق منه بعد ذلك؟
لا يزال نظام النشر يعرض المراجعة A ضمن المخرجات المنشورة تأكد من نشر المراجعة B أو إعادة بنائها بنجاح.
المخرجات المنشورة هي المراجعة B، لكن إعادة تحميل الشبكة في المتصفح تتلقى المراجعة A تحرَّ عن ذاكرة التخزين المؤقت المشتركة أو المستند الذي يقدمه المضيف.
تعرض إعادة تحميل الشبكة المراجعة B، بينما تعرض إعادة التحميل العادية المراجعة A تحرَّ عن التخزين المؤقت المحلي للمتصفح وسياسة التخزين المؤقت للاستجابة.
تعرض الصفحة العامة المراجعة B، لكن المعلومات المفهرسة لدى Google لا تزال قديمة استخدم الاختبار المباشر في Search Console، ثم فكّر في طلب الفهرسة.

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

انشر المستند المعدّل قبل مسح ذاكرته المؤقتة

أولًا، سجّل عنوان URL العام الدقيق والتغيير المتوقع. في هذا المثال الافتراضي، الجملة المتوقعة هي «المراجعة B: دوائر ومربعات». استخدم جملة مميزة تناسب المستند أصلًا؛ فالهدف هو التعرّف على المخرجات الجديدة من دون الاعتماد على وقت فتح علامة التبويب.

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

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

مثال موثّق على لوحة تحكم Cloudflare

إذا كانت صفحتك العامة تستخدم التخزين المؤقت في Cloudflare، فإن إجراءات المسح الموثقة لملف واحد توفّر مسارًا عمليًا عبر المتصفح:

  1. افتح لوحة تحكم Cloudflare للموقع المعني وانتقل إلى Configuration.
  2. ضمن Purge Cache، اختر Custom Purge.
  3. ضمن Purge by، اختر URL.
  4. أدخل عنوان URL العام الدقيق لكل مستند متأثر.
  5. راجع الإدخالات واختر Purge.

ترد هذه التسميات والخطوات في تعليمات المسح لملف واحد من Cloudflare.

تحقّق من الحدود الموثقة قبل تكرار عملية المسح. فمسح إعادة توجيه يزيل استجابة إعادة التوجيه، لذا امسح عنوان URL للوجهة لتحديث محتواها. لا يمكن مسح بعض مفاتيح التخزين المؤقت المخصصة عبر نموذج لوحة التحكم الخاص بعناوين URL؛ وتوثّق Cloudflare المسح حسب البادئة أو الوسم ضمن البدائل. كما أن المسح لملف واحد لا يقبل أحرف البدل. قيود المسح والبدائل.

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

تحقّق من الاستجابة العامة على جهاز Mac لديك

افتح عنوان URL العام الحالي للصفحة في Chrome. اضغط Command–Option–I لفتح DevTools، ثم اختر Network. توثّق Chrome هذا الاختصار على Mac وتميّز بين إعادة التحميل العادية وإعادة التحميل القسري وإعادة التحميل بعد إفراغ ذاكرة التخزين المؤقت. فتح Chrome DevTools.

مع فتح DevTools، اختر Disable cache في لوحة Network وأعد تحميل الصفحة. توثّق Chrome أن هذا الإعداد يجعل عمليات إعادة التحميل العادية تتجاوز ذاكرة التخزين المؤقت الخاصة بها. أبقِ DevTools مفتوحًا أثناء التحقق. إعادة التحميل مع ذاكرة التخزين المؤقت أو من دونها.

اختر طلب المستند الرئيسي من قائمة الشبكة. افتح Headers لفحص ترويسات الاستجابة، وResponse لفحص المحتوى المُعاد. ابحث عن جملة المراجعة B المتوقعة في ذلك المستند. يشرح دليل الشبكة في Chrome كيفية فحص الطلبات الفردية والترويسات ومحتوى الاستجابة. فحص نشاط الشبكة.

سجّل ثلاث ملاحظات: عنوان URL المطلوب، وما إذا كان المستند المُعاد يتضمن المراجعة B، وترويسات التخزين المؤقت المرفقة به. يتيح ذلك مقارنة مفيدة بعد المسح. نجاح العملية في لوحة التحكم نقطة تحقق؛ أما تلقي المستند المقصود فهو نقطة التحقق التي تجيب عن حاجة القارئ الفورية.

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

يوضح معيار WHATWG Fetch أهمية أوضاع جلب المتصفح. إذ يتجاوز الوضع reload ذاكرة HTTP المؤقتة للمتصفح في طريقه إلى الشبكة، ويحدّث تلك الذاكرة من الاستجابة. أما الوضع no-cache فيرسل طلبًا مشروطًا عند وجود استجابة مخزنة مؤقتًا. هذه سلوكيات للطلبات، ولذلك لا يُعد أي منهما مسحًا عامًا للصفحات المخزنة مؤقتًا بصورة مشتركة. معيار Fetch: أوضاع تخزين الطلب مؤقتًا.

اختر سياسة تخزين مؤقت تناسب التعديلات المستقبلية

بالنسبة إلى مستند عام ينبغي التحقق منه قبل كل إعادة استخدام، فكّر في توجيه الاستجابة Cache-Control: no-cache. فهو يسمح بالتخزين، لكنه يشترط نجاح التحقق قبل إعادة الاستخدام. أما Cache-Control: no-store فيمنع التخزين. وتحدد max-age الخاصة بالاستجابة مدة صلاحيتها؛ بينما تنطبق must-revalidate بعد انتهاء صلاحيتها. وتعالج هذه التوجيهات متطلبات مختلفة. RFC 9111: توجيهات Cache-Control للاستجابة.

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

لا يمكن لتغيير السياسة في استجابة منشورة حديثًا إخطار متصفح ما زال يعيد استخدام استجابة قديمة سارية من دون الاتصال بالخادم. لذلك تظل النسخ المخزنة مؤقتًا الموجودة جزءًا من مرحلة الانتقال. وينتج ذلك عن قواعد HTTP الخاصة بالصلاحية وإعادة الاستخدام؛ ولهذا ينبغي أن يصاحب إعداد ترويسة جديدة خطة صريحة للنسخ الموجودة. RFC 9111: إنشاء الاستجابات من ذاكرات التخزين المؤقت.

تأكد من أن التحقق يتعرّف على المراجعة

يحدد ETag تمثيلًا لاستخدامه في التحقق. وتوفر Last-Modified وقت تعديله. اطلب من الخادم إنشاء مُعرّفات تحقق تعكس التمثيل المنشور، بما يشمل التغييرات ذات الصلة في المحتوى المركّب من مصادر أخرى. يصف RFC 9110 كلا المُعرّفين ويوضح أن وسوم الكيان قد تميّز بين التمثيلات بدقة أكبر من تواريخ التعديل في بعض الحالات. RFC 9110: حقول التحقق.

تعني استجابة 304 Not Modified أن على المستلِم إعادة استخدام تمثيل مخزن صالح بدلًا من نقل المستند مجددًا. وهذا أمر طبيعي عندما تظل المراجعة المخزنة هي الأحدث. إذا تلقيت هذه النتيجة بينما لا تزال ترى المراجعة A بعد تأكيد تغيّر المحتوى، فتحرَّ عن التمثيل ومُعرّف التحقق اللذين قيّمهما الخادم. RFC 9110: 304 Not Modified.

اطلب من Google إعادة زيارة الصفحة المصححة

بعد أن يقدّم المستند العام المراجعة B باستمرار، افحص عنوان URL الكامل له ضمن الموقع المناسب في Search Console. اختر Test live URL لفحص الصفحة الحالية. قارن النتيجة بالتقرير المفهرس، الذي قد يصف عملية زحف أقدم. يفحص الاختبار المباشر الصفحة الحالية، لكنه لا يثبت بحد ذاته أن فهرس Google قد تحدّث. أداة فحص عنوان URL.

لطلب إعادة فهرسة صفحة محدّثة بعينها، اختر Request indexing في نتيجة الفحص. يجب أن تكون مالكًا للموقع في Search Console أو مستخدمًا كامل الصلاحيات فيه. يقول Google إن الزحف قد يستغرق من بضعة أيام إلى بضعة أسابيع، وإن تكرار الطلبات لا يسرّعه، وإن طلب الزحف لا يضمن ظهور الصفحة في نتائج البحث. اطلب من Google إعادة الزحف إلى عناوين URL.

لتحديث صفحات كثيرة، يوصي Google بإرسال خريطة موقع. احرص على دقة قيم <lastmod> فيها: يقول Google إنها ينبغي أن تعكس التغييرات المهمة، مثل تحديثات المحتوى الرئيسي، لا التغييرات الروتينية على تاريخ حقوق النشر. تساعد خريطة الموقع في الإبلاغ عن المستندات التي تغيّرت؛ لكنها لا تمسح نسخ المتصفح أو CDN. إنشاء خريطة موقع وإرسالها.

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

المصادر