اللغات

التخزين المؤقت لـSEO

كيف يحسن التخزين المؤقت للمتصفح والخادم باستخدام Cache-Control وETag وCDNs الأداء وCore Web Vitals، وأخطاء التخزين المؤقت التي تؤثر في الزحف.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2

يخزن التخزين المؤقت نسخة من صفحة أو مورد — في المتصفح أو عند حافة CDN أو في ذاكرة الزاحف — كي لا يعاد توليده أو تنزيله. وليس عامل ترتيب مباشرًا، لكنه يغذي شيئين مهمين: سرعة الصفحة/Core Web Vitals (عبر TTFB وLCP) وكفاءة الزحف. لا يحترم زاحف Google إلا ETag وLast-Modified (مع قراءة max-age كتلميح لإعادة الزحف) — ويفضل ETag، و«توجيهات التخزين المؤقت الأخرى عبر HTTP غير مدعومة». وأخطر أخطاء التخزين ليست مددًا بطيئة، بل إعدادات CDN خاطئة وذاكرات قديمة تحجب الروبوتات أو تضللها.

الخلاصة — يعمل التخزين المؤقت على ثلاث طبقات تهم SEO: المتصفح، وحافة CDN، وذاكرة طلبات الزاحف الشرطية الخاصة به. وهو ليس عامل ترتيب، لكنه يدفع سرعة الصفحة (TTFB/LCP، ومؤشرات Core Web Vitals عند التنقل المتكرر عبر bfcache) وكفاءة الزحف. يفضل زاحف Google ETag على Last-Modified، ويقرأ max-age كتلميح لإعادة الزحف فقط، ووفق وثائقه «توجيهات التخزين المؤقت الأخرى عبر HTTP غير مدعومة». وتكسب CDNs سماحًا بمعدل زحف أعلى، لكن بعد أن تصبح ذاكرتها دافئة؛ أما المخاطر الحقيقية فهي إطلاقات الذاكرة الباردة وإعدادات CDN/WAF الخاطئة التي تحجب الروبوتات تمامًا.

Evidence for this claim Google's crawler documentation supports ETag/If-None-Match and Last-Modified/If-Modified-Since, prefers ETag when both are present, and says other HTTP caching directives are unsupported; Google's separate max-age advice is a recrawl-timing hint, not proof it follows browser cache semantics. Scope: Google crawling Confidence: high · Verified: Crawling December: HTTP caching Evidence for this claim HTTP caching uses Cache-Control and validators to control reuse and revalidation. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching Evidence for this claim Browser caches can reuse stored responses according to HTTP caching semantics. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching

طبقات التخزين المؤقت الثلاث

التخزين المؤقت لـSEO ليس شيئًا واحدًا — بل ثلاثة أشياء، يتحكم كل منها بطريقة مختلفة قليلًا:

  1. ذاكرة المتصفح المؤقتة — يخزن جهاز الزائر الملفات كي تتخطى المشاهدات المتكررة الشبكة. وهذا ما تكرر PageSpeed Insights التنبيه إليه بعبارة «قدّم الأصول الثابتة بسياسة تخزين مؤقت فعالة».
  2. ذاكرة CDN/الحافة — تخزن شبكة توصيل المحتوى نسخًا في عقد حافة حول العالم (انظر التعمق في CDN وSEO للتفاصيل). ووصف Google نفسه يقول إن CDNs وسيط بين الأصل والمستخدم، وإن أكبر تركيز تاريخي لها هو التخزين المؤقت — أي حفظ محتوى URL كي لا يضطر خادمك إلى خدمة الملف نفسه مدة من الوقت.
  3. ذاكرة الزاحف المؤقتة — يحتفظ Googlebot وBingbot بسجل خاصهما عما إذا تغير المحتوى، باستخدام الطلبات الشرطية. وهذه هي رافعة ميزانية الزحف؛ أما آلياتها فتخص التعمق في الطلبات الشرطية، وسأبقيها هنا في مستوى الملخص.

«ذاكرة المتصفح المؤقتة» أعلاه اختصار لأكثر من آلية. ووفق دليل MDN للتخزين المؤقت عبر HTTP، من المفيد معرفة الفرق بين ذاكرة HTTP الخاصة (لكل متصفح، ومفهرسة بحسب الطلب، ومقسمة في المتصفحات الحديثة بحسب الموقع الأعلى للحد من التتبع عبر المواقع)، والذاكرة الموجودة في RAM للجلسة الحالية، وbfcache المشروحة أدناه، و — منفصلة عنها — Cache Storage الخاصة بعامل الخدمة، التي يتحكم فيها JavaScript الخاص بالموقع ولا تتحكم فيها ترويسات Cache-Control مباشرةً. وقد تعني عبارة «تحقق من ذاكرة المتصفح» أربع خطوات تصحيح مختلفة بحسب الآلية التي تتعطل فعليًا.

لماذا يغذي التخزين المؤقت Core Web Vitals

إن جلب الموارد عبر الشبكة بطيء ومكلف. ويزيل التخزين المؤقت زمن تأخر الشبكة وتكلفة النقل لأي شيء لم يتغير. وينعكس ذلك مباشرةً على مقياسين قريبين من المؤشرات: TTFB (فالاستجابة المخزنة مؤقتًا تتخطى إعادة التوليد عند الأصل) وLCP (فالصور وCSS والخطوط المخزنة مؤقتًا تُعرض أسرع).

Cache-Control، في التوجيهات المهمة

Cache-Control هي الترويسة الرئيسية. وهذه التوجيهات تستحق المعرفة:

  • max-age=<seconds> — مدة صلاحية النسخة الجديدة. وبالنسبة إلى الأصول غير القابلة للتغيير ذات الإصدارات، توصي وثائق Lighthouse في Chrome بالتخزين لسنة أو أكثر — مثلًا Cache-Control: max-age=31536000.
  • no-cache — ليست «لا تخزن». معناها «خزنها، لكن أعد التحقق مع الخادم قبل إعادة استخدامها». وهي لا تزال تتيح تدفق 304 الخفيف.
  • no-store — التوجيه الذي يعني فعلًا عدم تخزين أي نسخة في أي ذاكرة مؤقتة عبر HTTP. إنه توجيه تخزين مؤقت لا مفتاح خصوصية عام — فوفق RFC 9111 ليس طريقة موثوقة لمحو سجل المتصفح، ولا يقول شيئًا عن Cache Storage الخاصة بعامل الخدمة.
  • public / private — هل تستطيع الذاكرات المشتركة (مثل CDN) تخزين الاستجابة، أم لا يستطيع ذلك إلا متصفح المستخدم النهائي.
  • immutable — تخطَّ إعادة التحقق تمامًا ما دامت الاستجابة جديدة. ولا يعني ذلك «لن تصبح قديمة أبدًا» — فعند انتهاء max-age تعود قواعد الجدة العادية.
  • must-revalidate — الطرف المقابل في الخط الزمني: لا يهم إلا بعد أن تصبح الاستجابة قديمة، ويخبر الذاكرة بضرورة إعادة التحقق مع الأصل بدل تقديم النسخة القديمة على أي حال.
  • s-maxage وstale-while-revalidate وstale-if-error — ضوابط أدق أساسًا لـCDNs والذاكرات المشتركة الأخرى (عمر جدة منفصل للذاكرات المشتركة، وإعادة استخدام قديم محدودة أثناء جلب في الخلفية، وإعادة استخدام قديم محدودة عند خطأ الأصل). يختلف الدعم بحسب المتصفح/CDN، فتحقق من الدعم الحالي قبل الاعتماد عليها — ولا يحترم زاحف Google مجموعة التوجيهات الإضافية هذه، كما سنرى.

منع التخزين المؤقت بأسماء ملفات ذات إصدارات

الحيلة التي تتيح لك التخزين المؤقت المكثف والتحديث الفوري: ضع تجزئة المحتوى في اسم الملف — style.x234dff.css. وبما أن URL هو مفتاح الذاكرة المؤقتة، فإن تغيير الملف يغير URL، فتجلب الذاكرات النسخة الجديدة فورًا بينما تظل النسخ القديمة مخزنة ما تشاء. ويصف كل من دليل web.dev لذاكرة HTTP والكتابة الهندسية الخاصة بالواجهة الأمامية في Bing النمط نفسه — إذ تجزئ Bing محتوى الملف في URL كي “the URL acts as the cache key,” (ترجمة) «يعمل URL بوصفه مفتاح الذاكرة المؤقتة»، ما يبقي الذاكرات متسقة ويسمح بمدد انتهاء طويلة.

فخ bfcache — حيث يضر no-store بمؤشرات CWV بهدوء

إليك نقطة لا تحظى بتغطية كافية. ذاكرة الرجوع/التقدم (bfcache) هي ما يجعل الضغط على «رجوع» يعيد الصفحة فورًا. وتتخطى استعادة bfcache قياس LCP/CLS/INP بالكامل، لذلك فهي مكسب صافٍ لبيانات CrUX الحقلية. لكن وفق دليل Google لـbfcache، جعل Cache-Control: no-store في وثيقة الصفحة نفسها المتصفحات ترفض تاريخيًا تخزين الصفحة في bfcache. فإذا كنت تحتاج إلى الجدة في وثيقة HTML ولا تريد التضحية بأهلية ذاكرة الرجوع/التقدم، فاستخدم no-cache أو max-age=0 بدلًا من no-store.

كيف تقرر الذاكرة أن المحتوى «جديد بما يكفي»

قبل إشراك أي أداة تحقق، تفحص الذاكرة الجدة: هل تجاوز عمر الاستجابة المخزنة مدة الجدة التي منحتها Cache-Control (أم — عند غياب عمر صريح — مدة استدلالية يُسمح للذاكرة بتخمينها)؟ وتبلغ ترويسة استجابة Age المدة التي احتفظت فيها ذاكرة مشتركة بالاستجابة، وبذلك تعرف — في أدوات المطور أو من سجل CDN — مقدار مدة الجدة المتبقية. إذا كانت جديدة، يمكن للذاكرة إعادة استخدامها فورًا بلا أي طلب. وإذا كانت قديمة، ينبغي أن تتحقق قبل إعادة الاستخدام؛ وهنا بالضبط تكسب ETag/If-None-Match وLast-Modified/If-Modified-Since قيمتها — وسنصف ذلك لاحقًا، في النسخة الأضيق من آلية HTTP العامة الخاصة بـGooglebot.

كيف يستخدم Googlebot التخزين المؤقت (زاوية كفاءة الزحف)

قدمت Google طلبًا مباشرًا على نحو غير معتاد في منشور ديسمبر الزحف: التخزين المؤقت عبر HTTP في ديسمبر 2024: فعّل التخزين المؤقت كي تتخطى زواحفها إعادة تنزيل الصفحات التي لم تتغير. والنقطة اللافتة في المنشور أن الجلب القابل للتخزين المؤقت كان ينخفض — نحو 0,026 % من إجمالي عمليات الجلب كان قابلًا للتخزين المؤقت قبل 10 سنوات، واليوم تبلغ النسبة 0,017 %. أرقام صغيرة، لكن Google تريد بوضوح أن تتحرك في الاتجاه الآخر.

ETag مقابل Last-Modified — أيهما تفضل Google

تدعم بنية زحف Google أداتي التحقق القياسيتين: ETag (مع If-None-Match) وLast-Modified (مع If-Modified-Since). وتوصي Google بشدة باستخدام ETag لأن قيمته غير منظمة، ولذلك أقل عرضة لأخطاء التحليل التي تستدعيها سلسلة التاريخ — وإذا وُجد الاثنان، فإن زواحفها تستخدم قيمة ETag كما يقتضي معيار HTTP. ومع ذلك تقترح Google ضبط الاثنين، لأن تطبيقات أخرى مثل CMS تستخدمهما. وإذا استخدمت Last-Modified، فيجب أن يتبع التاريخ تنسيق HTTP (مثل Fri, 4 Sep 1998 19:15:56 GMT) وإلا فلن يُحلل.

عندما يظل أداة التحقق المخزنة لدى الزاحف مطابقة، يعيد خادمك 304 Not Modified بلا جسم — وهذه هي الفكرة كلها. وكما تقول Google، يعني غياب الجسم أن خادمك لا ينفق قدرة حوسبة على توليد المحتوى ولا ينفق نطاقًا تردديًا على نقله. (وتغطي مقالة الطلبات الشرطية هذه الآلية بعمق بوصفها آلية ميزانية الزحف؛ ويكفي هنا أن تعرف أنها موجودة وتوفر المال على الجانبين.)

التفصيل الذي يفوته الجميع تقريبًا

لا يتصرف زاحف Google وفق مجموعة توجيهات Cache-Control الكاملة كما يفعل المتصفح أو CDN. فوفق نظرة الزاحف الرسمية، لا يدعم — إلى جانب ETag/Last-Modified — «توجيهات التخزين المؤقت الأخرى عبر HTTP». والاستثناء الجزئي الوحيد هو أن Google تقول إنك تستطيع ضبط max-age اختياريًا لمساعدة الزواحف في تحديد موعد إعادة زحفها إلى URL — وهو تلميح لإعادة الزحف لا قفل صارم. لذلك لا تزال no-cache وs-maxage وstale-while-revalidate وما شابهها تشكل سلوك المتصفح وCDN، لكنها لا تغير طريقة تخزين Googlebot المؤقت. ونصيحة Google حول وقت الإبطال منطقية: اطلب تحديث الذاكرة عند التغييرات المهمة — فتحديث تاريخ حقوق النشر في التذييل وحده ليس مهمًا.

CDNs والزحف

يشتري لك CDN أكثر من السرعة. وتقول Google إن “Our crawling infrastructure is designed to allow higher crawl rates.” (ترجمة) «صُممت بنية زحف Google للسماح بمعدلات زحف أعلى»، وذلك للمواقع المدعومة بـCDN، وتستنتج ذلك من عنوان IP الذي يخدم عناوين URL — إذ تفترض أن أصلًا مدعومًا بـCDN يستطيع التعامل مع طلبات متزامنة أكثر.

لكن هناك نقطة تستحق التخطيط: الذاكرة الباردة. عند أول وصول إلى URL تكون ذاكرة CDN «باردة» — فلا أحد طلبه بعد، ولذلك لا يزال على الأصل خدمته مرة واحدة على الأقل لتدفئة الذاكرة. وتحذر Google من أن إطلاق عناوين URL كثيرة دفعة واحدة يمثل عبئًا حقيقيًا على ميزانية الزحف، مع معدل زحف مرتفع لبضعة أيام. فإذا كنت تطلقًا كبيرًا أو ترحّل موقعًا، فخطط لتحمل الأصل الحمل الكامل لكل URL قبل أن يبدأ CDN بالمساعدة.

إعداد CDN الخاطئ خطر على الزحف

أكثر المشكلات المخيفة القريبة من التخزين المؤقت ليست مددًا بطيئة — بل إعدادات CDN وWAF التي تحجب الروبوتات. وتوضح مقالة Google عن CDN أن إرسال 503/429 هو الطريقة المفضلة للإشارات إلى الحجب المؤقت، بينما تُعامل مهلات الشبكة بوصفها أخطاء نهائية «قاسية» قد تزيل عناوين URL من الفهرس. أما الدقيقة فهي الحجب الناعم: صفحة وسيطة للتحقق من الروبوت. لا يرى الزاحف إلا صفحة التحدي لا موقعك — ولذلك توصي Google بشدة بإعادة 503 إلى العملاء الآليين بدلًا من ذلك. وأسهل طريقة للتحقق من أن CDN لا يحجب Google سرًا هي أداة فحص URL في Search Console — انظر إلى الصورة المعروضة؛ فإذا أظهرت تحدي روبوت أو صفحة فارغة، فتحدث إلى CDN.

أنا من محبي تفويض عمليات إعادة التوجيه إلى CDN. وقد وصفت ذلك في بودكاست Marketing Speak بأنه “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (ترجمة) «إحدى المفضلات الشخصية لدي التي لا أظن أنها تُستخدم بما يكفي: تفريغ عمليات إعادة التوجيه إلى مستوى CDN.» (الانتقال إلى الاقتباس)

أخطاء التخزين المؤقت التي تضر الزحف والفهرسة

هذه هي الزاوية التي تتخطاها معظم مقالات «التخزين المؤقت لـSEO». فالذاكرة المؤقتة لا تجعل الأشياء سريعة فقط — ويمكن لذاكرة خاطئة أن تقدم البايتات الخطأ إلى روبوت وتكسر الزحف أو الفهرسة.

حالة حقيقية: ذاكرة مشتركة تقدم robots.txt حاجبًا. بحثت في حالة حجب متقطع لـGooglebot، وتبين أنها تعود إلى ذاكرة CDN مشتركة بين بيئة اختبار والموقع الحي. وكما كتبت في مفهرسة رغم حجبها بواسطة robots.txt: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (ترجمة) «قد يكون أحد الأسباب المحتملة ذاكرة مشتركة بين بيئة اختبار وبيئة حية. وعندما تكون ذاكرة بيئة الاختبار نشطة، قد يتضمن ملف robots.txt توجيهًا حاجبًا.» وكان الحل فصل الذاكرة — أو استبعاد ملفات .txt من الذاكرة في بيئة الاختبار. تسبب إعداد خاطئ للتخزين المؤقت مباشرةً في فشل زحف؛ وهذا هو نوع الخطر الذي يعض فعلًا.

مشكلات أخرى من العائلة نفسها:

  • ذاكرة CDN قديمة تقدم محتوى منتهي الصلاحية إلى الروبوتات. إذا احتفظت ذاكرة الحافة بنسخة قديمة بعد وقت طويل من نشر تغيير، فستستمر الروبوتات في رؤية النسخة القديمة. أفرغ الذاكرة عند النشر، أو اربط عمرها بعدد مرات تغير الصفحة فعليًا.
  • تجزئة ذاكرة Vary / User-Agent. يكون مفتاح الذاكرة المشتركة عادةً URL وحده؛ ويضيف Vary ترويسات الطلب (مثل User-Agent أو Accept-Language) إلى ذلك المفتاح كي تُخزن النسخ المختلفة منفصلة. إذا أسقطت ترويسة تغير الاستجابة فعلًا، فقد يحصل طالب على نسخة طالب آخر — خلط المحمول/سطح المكتب أو الروبوت/الإنسان. وإذا أضفت ترويسات كثيرة إلى Vary، جزأت الذاكرة إلى مفاتيح متشابهة كثيرة بحيث لا تحسن معدل الإصابة إلا قليلًا. ومنفصلًا عن ذلك، تقسم المتصفحات الحديثة ذاكرتها الخاصة أيضًا بحسب الموقع الأعلى للخصوصية، ولذلك لا يعاد استخدام مورد مخزن أثناء تضمينه في موقع عادةً عند تضمينه في موقع آخر — وهي آلية مختلفة عن Vary، فلا تخلط بينهما عند تصحيح تقرير «لماذا لم يُخزن هذا؟».

تأتي قاعدتي العامة التقريبية للمدة من عمل LCP: كما قلت في دليلي على Ahrefs عن Largest Contentful Paint، “Your cache time should be as long as you are comfortable with” (ترجمة) «ينبغي أن تكون مدة التخزين المؤقت طويلة بقدر ما تشعر معه بالارتياح.» (الانتقال إلى الاقتباس) — و*“An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.”* (ترجمة) «الإعداد المثالي هو التخزين المؤقت لفترة طويلة جدًا، مع إفراغ الذاكرة المؤقتة عند إجراء تغيير على صفحة.» تخزين طويل، وإفراغ فوري. وهذه التركيبة هي ما يبقيك سريعًا وجديدًا في آن واحد.

هل التخزين المؤقت عامل ترتيب؟

لا — ليس مباشرةً. لا توجد إشارة ترتيب لمجرد ضبط ETags أو سياسة Cache-Control جيدة. ما يفعله التخزين المؤقت هو تغذية شيئين مهمين للظهور: سرعة الصفحة/Core Web Vitals (مدخل صريح لتجربة الصفحة) وكفاءة الزحف (التي تحدد سرعة اكتشاف المحتوى الجديد والمحدث وتحديثه، فتلامس النتائج الحساسة للجدة بصورة غير مباشرة). اضبطه لأنه يجعل موقعك سريعًا وسهل الزحف — لا لأنك تتوقع زيادة مباشرة في الترتيب.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.