p>بعد تعديل Robots.txt، تنقسم استجابة Google إلى مرحلتين: “زحف الملف” و”سريان الفهرسة”.
عادةً ما يعيد Googlebot قراءة هذا الملف خلال 24 ساعة، ولكن التغييرات الفعلية في نتائج البحث (الفهرسة) تستغرق عادةً من 3 إلى 10 أيام.
من أجل الامتثال لمبادئ الإدارة الفعالة لتحسين محركات البحث (EEAT)، نوصيك بزيارة Google Search Console فورًا بعد التعديل.
قم بتقديم التحديث يدويًا من خلال “أداة اختبار Robots.txt”، واستخدم أداة “فحص عنوان URL” لطلب إعادة الفهرسة للصفحات الأساسية.
يمكن لهذا التدخل الاستباقي تقليل وقت التنفيذ إلى أقل من 48 ساعة، مما يضمن تحسين ميزانية الزحف (Crawl Budget).
تحديث الزحف التلقائي
يلتزم Googlebot بمعيار RFC 9309، ويقوم افتراضيًا بضبط فترة ذاكرة التخزين المؤقت لملف robots.txt لمدة 24 ساعة.
يطلب برنامج الزحف هذا الملف مرة واحدة على الأقل يوميًا؛ إذا أرجع الخادم 304 Not Modified، فسيستمر Google في استخدام التعليمات القديمة؛
أما إذا أرجع 200 OK وكان حجم الملف أقل من 500 KB، فستحل القواعد الجديدة محل ذاكرة التخزين المؤقت.
عادةً ما يكون تأخير المزامنة للتحديث التلقائي في غضون 24 ساعة، ولكن حذف الفهرسة أو استعادتها في صفحات نتائج البحث يعتمد على تخصيص ميزانية الزحف، ويستغرق عادةً ما بين 3 إلى 10 أيام.
ميزانية الزحف
ميزانية الزحف ليست قيمة ثابتة؛ عند التعامل مع robots.txt، يعطي Googlebot الأولوية دائمًا لاستهلاك الميزانية للحصول على هذا الملف.
إذا كانت ميزانية الزحف للموقع كافية، فسيكون تواتر زيارة Googlebot لـ /robots.txt أعلى بكثير من المواقع العادية.
بالنسبة لمنصات التجارة الإلكترونية الكبيرة التي تنشئ عشرات الآلاف من عناوين URL الجديدة يوميًا، قد يكتشف Google تغييرات الملف كل بضع ساعات.
بينما في المواقع الصغيرة ذات الميزانية المنخفضة، سينفذ النظام بدقة دورة تخزين مؤقت مدتها 24 ساعة.
إذا تجاوز متوسط وقت استجابة الخادم لطلبات Googlebot ثانيتين، فسيقوم Google تلقائيًا بتقليل ميزانية الزحف لهذا الموقع.
هذا النقص في الميزانية سيؤثر على اكتشاف تحديثات robots.txt.
عندما يعيد الخادم عددًا كبيرًا من أخطاء 5xx تحت الحمل العالي، سيقوم Googlebot، لحماية الخادم المضيف، بتقليل تواتر الاكتشاف بشكل كبير، بل وقد يتوقف عن تحديث تعليمات robots المخزنة مؤقتًا، وينتقل بدلاً من ذلك إلى فترة احتفاظ بالتعليمات تصل إلى 35 يومًا.
في هذه الحالة، حتى لو اكتمل تعديل الملف على جانب الخادم، سيستمر نظام الجدولة في استخدام الذاكرة المؤقتة القديمة لتخصيص حصص الزحف.
| مستوى الموقع | حجم طلبات الزحف اليومية المقدر | تواتر اكتشاف robots.txt | وقت استشعار تفعيل القواعد |
|---|---|---|---|
| المستوى الأول (ملايين الصفحات) | أكثر من 100,000 مرة | مرة كل 4 – 6 ساعات | خلال 12 ساعة |
| المستوى الثاني (مئات الآلاف من الصفحات) | 1,000 – 50,000 مرة | مرة كل 12 – 24 ساعة | حوالي 24 ساعة |
| المستوى الثالث (أقل من 10 آلاف صفحة) | أقل من 500 مرة | مرة كل 24 – 48 ساعة | أكثر من 48 ساعة |
إذا نشر موقع ما مؤخرًا كمية كبيرة من التقارير الأصلية أو صفحات المنتجات عالية الجودة، فسترفع خوارزمية الجدولة في Google أولوية الزحف الخاصة به.
تحت دفع هذا “الطلب العالي”، سيطلب Googlebot الدليل الجذري بشكل متكرر، ويقوم بالمناسبة بالتحقق من إصدار robots.txt.
تظهر المؤشرات الفنية من مركز بحث Google أن عدد الصفحات ذات قيمة PageRank العالية يرتبط طرديًا بميزانية الزحف.
النطاقات التي تمتلك روابط خارجية عالية الجودة، عادةً ما تكون سرعة التحديث التلقائي لملف robots.txt الخاص بها أسرع بنسبة 300% من المواقع الجديدة بدون روابط خارجية.
عند التعامل مع ملفات robots.txt التي تحتوي على كم هائل من القواعد، فإن حد التحليل البالغ 500 KB سينتج عنه تفاعل معقد مع ميزانية الزحف.
إذا كان الملف يحتوي على عدد كبير من رموز المطابقة المنتظمة (مثل * و $)، فسترتفع تكلفة تنفيذ منطق التصفية لمحلل Googlebot في كل جولة تحديث تلقائي.
بالنسبة للمواقع ذات ميزانية الزحف المحدودة، ستؤدي مجموعة القواعد غير الفعالة هذه إلى عدم قدرة الزاحف على إكمال التنقل الفعال في الأدلة العميقة خلال وقت الاتصال المحدود، مما يظهر في تقرير GSC كزيادة حادة في قيم “تم الزحف إليه – لم يتمت فهرسته بعد”.
فيما يلي مؤشرات البيانات المحددة التي تؤثر على التوافق بين ميزانية الزحف وسرعة التحديث:
- عتبة حمل المضيف (Host Load): يجب أن يظل معدل استجابة الخادم 200 OK المستقر أثناء الزحف المتزامن أعلى من 99%، وإلا ستنخفض الميزانية تلقائيًا.
- كثافة تعليمات URL: إذا تجاوزت مسارات Disallow في ملف واحد 10,000 سطر، فسيؤدي ذلك إلى زيادة عبء الحوسبة على المحلل عند تحديث ذاكرة التخزين المؤقت بشكل كبير.
- متوسط تأخير الاستجابة: إذا كان وقت حصول Googlebot على
robots.txtمستقرًا في غضون 200 مللي ثانية، فسيميل النظام إلى زيادة تواتر الاكتشاف. - نسبة استجابة 304: إذا أعاد الخادم تعليمات 304 بشكل متكرر، فسيعتبر Googlebot أن محتوى الملف مستقر، مما يؤدي إلى تأخير نافذة الاكتشاف التلقائي التالية إلى الحد الأقصى البالغ 24 ساعة.
في “طلبات الزحف حسب الغرض”، تعكس نسبة فئة “إعادة المزامنة” نسبة الميزانية التي يستهلكها Googlebot للحفاظ على حداثة التعليمات.
إذا كانت هذه النسبة أقل من 1% من إجمالي حجم الزحف، وكان الموقع يمر بفترة تعديل مسارات واسعة النطاق، فسيصبح تأخير التحديث التلقائي غير قابل للتحكم.
في هذه المرحلة، سيستمر الزحف للمجلدات المحظورة بالفعل، لأن تعليمات ذاكرة التخزين المؤقت القديمة لم يتم استبدالها بعد في مجمع الجدولة.
بالنسبة للمواقع المستضافة على شبكات توصيل المحتوى (CDN)، قد تتداخل استراتيجيات التخزين المؤقت لعقد CDN أحيانًا مع حكم Googlebot على ميزانية الزحف. إذا استمرت CDN في إرجاع استجابة بـ Etag قديم لـ Googlebot بعد تغيير
robots.txt، فسيعتقد Google خطأً أن الملف لم يتحدث، مما يؤدي إلى إنهاء المزامنة التلقائية الحالية. تشيع هذه الحالة في بيئات الاستضافة الموزعة في أمريكا الشمالية وأوروبا، وتتطلب عادةً ضبط مدة صلاحية ذاكرة التخزين المؤقت لملفrobots.txtفي CDN قسريًا على 0 أو استخدام ترويسة no-cache.
عندما يمر الموقع بتعديلات واسعة النطاق في robots.txt، قد تظل آلاف الصفحات التي كان مسموحًا بزحفها سابقًا تسجل عمليات زحف خلال أول 48 ساعة بعد تعديل القواعد.
فقط عندما تتم مزامنة ذاكرة التخزين المؤقت لملف robots.txt الجديد تمامًا مع جميع عقد مجموعات الزحف في Google، سيتم إلغاء مهام الزحف القديمة هذه من قبل النظام بشكل جماعي.
الأداء بعد التحديث
في الحالة الطبيعية، يجب أن تغطي استجابة robots.txt بـ 200 (OK) أو 304 (Not Modified) سجلات الطلبات بنسبة 100%.
إذا ارتفعت نسبة رموز الحالة 4xx أو 5xx، فهذا يشير إلى حدوث انحراف في تكوين الخادم عند التعامل مع طلبات التحقق التلقائي من Googlebot.
خلال 24 إلى 48 ساعة بعد التحديث التلقائي، ستلاحظ نقطة تحول واضحة في مخطط “إجمالي عمليات الزحف”.
إذا كانت التعليمات الجديدة تحظر أدلة يتم زحفها بشكل متكرر، فإن تواتر طلبات User-Agent لـ Googlebot في سجلات الخادم (Server Logs) سينخفض من عشرات المرات في الدقيقة إلى الصفر.
| مؤشر المراقبة | أداء التحديث التلقائي الطبيعي | أداء الحالة غير الطبيعية |
|---|---|---|
| رمز استجابة robots.txt | البقاء باستمرار على حالة 200 أو 304. | ظهور 403 رفض الإذن أو 503 الخدمة غير متوفرة. |
| نوع طلب الزحف | اختفاء طلبات “استخراج المحتوى” للمسارات المحظورة. | استمرار تسجيل عمليات زحف 200 بكثافة للمسارات المحظورة. |
| تغطية الفهرس | ارتفاع عدد “المحظورة بواسطة robots.txt” تحت فئة “المستبعدة”. | عدم انخفاض عدد الصفحات “الصحيحة” مع تعديل robots.txt. |
| مؤشر حمل المضيف | انخفاض ضغط حمل الخادم مع توسع نطاق الحظر. | زيادة ضغط الزحف بدلاً من انخفاضه، احتمال وجود تعارض في قواعد التعليمات. |
وفقًا لمواصفات بروتوكول RFC 9309، سيلتزم Googlebot بدقة بـ حد 500 KB عند معالجة robots.txt تلقائيًا. إذا تجاوز محتوى الملف هذا الحد بعد التحديث التلقائي، فسيقوم Google فقط بقراءة وتنفيذ أول 500 KB من التعليمات. في أداء البيانات، سيؤدي ذلك إلى فشل قواعد Disallow الموجودة في نهاية الملف، وستستمر الصفحات التي لا ينبغي زحفها في الظهور في نتائج البحث.
من منظور التغذية الراجعة على مستوى الفهرسة، بعد اكتمال التحديث التلقائي، لن يقوم Google بمسح الصفحات المحظورة بموجب القواعد الجديدة من قاعدة البيانات على الفور.
عادةً ما تمر صفحات نتائج البحث (SERP) بفترة انتقالية تتراوح من 3 إلى 10 أيام.
خلال هذه الفترة، سيتغير عنوان الصفحة ووصفها (Snippet)، ليظهر نص بديل قياسي مثل “لا يتوفر وصف لهذه الصفحة بسبب ملف robots.txt الخاص بهذا الموقع”.
إذا أدخلت عنوان URL المتأثر في “أداة فحص العناوين” في Search Console، فسيعيد النظام علامة حالة “تمت الفهرسة، ولكن تم الحظر بواسطة robots.txt”.
| مرحلة التحديث | خصائص البيانات | اقتراحات التشغيل المقابلة |
|---|---|---|
| اليوم 1-2 | زيادة طلبات robots.txt في سجلات الخادم، واكتمال إعادة تعيين ذاكرة التخزين المؤقت. | التحقق مما إذا كان هناك أخطاء 5xx في “إحصاءات الزحف” في GSC. |
| اليوم 3-5 | بدء إعادة توزيع ميزانية الزحف، وارتفاع حجم الزحف للمسارات المسموح بها حديثًا. | مراقبة ما إذا كان تواتر الزحف للمجلدات المفتوحة حديثًا يتوافق مع التوقعات. |
| اليوم 7-14 | اكتمال المزامنة واسعة النطاق لقاعدة بيانات الفهرس، واختفاء أوصاف الصفحات القديمة. | التحقق مما إذا كانت SERP لا تزال تحتوي على روابط معطلة مع نصوص بديلة. |
من خلال تحليل طلبات نطاقات IP الخاصة بـ Googlebot، ستجد أن Google يقوم باكتشاف إلزامي لملف robots.txt كل 24 ساعة.
في سجلات البيانات، عادةً ما يحمل هذا الطلب معلومات تحقق من googlebot-id.
إذا دخل التحديث التلقائي حيز التنفيذ، فستتحول طلبات GET الموجهة للأدلة المحظورة بسرعة إلى 0.
بالنسبة للمواقع الكبيرة التي تمتلك أكثر من مليون صفحة، سيؤدي هذا الانخفاض في تواتر الزحف إلى تحرير المزيد من حصص الزحف، وستحصل الصفحات ذات القيمة العالية التي كان تواتر زحفها منخفضًا سابقًا (مثل صفحات الأخبار أو تفاصيل المنتجات المنشورة مؤخرًا) على فرص زحف أكبر.
في هذه المرحلة، سيظهر عدد الصفحات في حالة “تم اكتشافها – لم يتمت فهرسته حاليًا” في GSC اتجاهًا نزوليًا.
تعتمد خوارزمية التحديث التلقائي في Google على ترويسة HTTP Last-Modified. إذا تم تكوين الخادم بوقت تعديل أخير دقيق، يمكن لـ Googlebot مقارنة الفرق بين ذاكرة التخزين المؤقت المحلية وملف الخادم بشكل أكثر فعالية عند إجراء التحديث التلقائي. إذا ظل حجم الملف كما هو ولم يتغير تاريخ الترويسة، فقد ينهي Googlebot فحص التحديث الحالي بإرسال رمز حالة 304، مما يوفر موارد الزاحف.
بالنسبة لتلك الصفحات التي كانت تحتل المراتب الثلاث الأولى في البحث، غالبًا ما تكون سرعة حذف ذاكرتها المؤقتة أبطأ من الصفحات العميقة.
يمكنك إجراء فحص عينة للبيانات في مربع البحث باستخدام أمر site مع صيغة inurl:.
إذا وجدت أن بعض الأدلة الخاصة لا تزال تظهر عناوينها في نتائج البحث بعد 14 يومًا من التحديث التلقائي، فهذا يشير إلى أن الزحف التلقائي لملف robots.txt قد واجه مشكلة إعادة توجيه تكرارية، مما منع Googlebot من الحصول على قواعد النص النهائية.
تحديث يدوي عبر Search Console
في لوحة “الإعدادات” في GSC، يمكن من خلال تقرير robots.txt إجبار Googlebot على تحديث ذاكرة التخزين المؤقت الافتراضية البالغة 24 ساعة.
بعد النقر على زر “طلب التحديث”، يقوم Google عادةً بإعادة استخراج الملف من الخادم خلال 10 إلى 30 دقيقة.
ستقوم هذه العملية بمزامنة حالة استجابة HTTP مع قاعدة بيانات فهرس Google؛ إذا كان رمز الحالة 200، فستتم معالجة القواعد الجديدة فورًا؛
وإذا تمت مواجهة خطأ 503، فسيقوم Googlebot بتأجيل الزحف.
طريقة التدخل هذه يمكن أن تقلل بشكل كبير دورة الـ 48 ساعة المطلوبة للتحديث الطبيعي إلى أقل من ساعة واحدة.
خطوات التشغيل
بعد تسجيل الدخول إلى Google Search Console، يجب تحريك الماوس إلى خيار “الإعدادات” في أسفل شريط التنقل الأيسر.
في صفحة الإعدادات، ابحث عن تقرير robots.txt تحت فئة “الزحف”.
انقر للدخول إلى التقرير، وستعرض الواجهة نسخة الملف المخزنة حاليًا في قاعدة بيانات Google.
يوضح الجزء العلوي من هذه الصفحة تاريخ آخر استخراج ناجح والطابع الزمني الدقيق بالثواني.
إذا تم إجراء تعديلات على الملف الموجود على الخادم، يجب النقر على زر “طلب التحديث” في الزاوية العلوية اليمنى من الصفحة.
سيؤدي هذا الإجراء إلى إطلاق طلب غير متزامن، لإبلاغ Googlebot بزيارة مسار /robots.txt تحت الدليل الجذري للموقع فورًا.
سيزور Googlebot الموقع باستخدام تواتر الزحف القياسي، وعادةً ما يكمل النظام الانتقال من حالة “تمت الإضافة إلى زمام الانتظار” إلى “تم الاستخراج بنجاح” خلال 10 إلى 15 دقيقة من النقر على الزر.
عندما يستخرج Googlebot ملف robots.txt، يتم تقييد الحد الأقصى لحجم الملف بدقة بـ 500 KB (حوالي 512,000 بايت). إذا أرجع الخادم ملفًا يتجاوز هذا الحد، فسيقرأ Google أول 500 KB فقط من المحتوى، وسيتم تجاهل الأجزاء المتبقية. سيؤدي سلوك القطع هذا إلى فشل تعليمات Allow أو Disallow الموجودة في نهاية الملف.
بعد النقر على زر التحديث، يجب أن يعيد الخادم حالة استجابة HTTP 200 OK.
إذا كان الخادم مزودًا بآلية تخزين مؤقت، مثل استخدام رؤوس الاستجابة ETag أو Last-Modified، فسيرسل Googlebot طلب If-Modified-Since.
إذا لم يتغير محتوى الملف على مستوى البايت، فسيعيد الخادم 304 Not Modified؛ في هذه الحالة، سيستمر تحديث الطابع الزمني للاستخراج في تقرير GSC، لكن محتوى الملف سيبقى كما هو.
إذا كان الملف الجديد يحتوي على أخطاء في الصيغة، مثل فقدان سطر User-agent أو استخدام أحرف بديلة غير قياسية، فسيشير تقرير GSC إلى رقم السطر المحدد للخطأ بعلامة حمراء في نافذة المعاينة.
تتطلب عملية التحديث اليدوي أن يكون ترميز الملف UTF-8؛ إذا تم استخدام تنسيقات ترميز أخرى تحتوي على علامة ترتيب البايت (BOM)، فقد لا يتمكن Googlebot من تحليل أول تعليمة في بداية الملف.
إذا كان الموقع يستخدم CDN (شبكة توصيل المحتوى) مثل Cloudflare أو Fastly، فيجب قبل النقر يدويًا على التحديث في GSC تنفيذ مسح ذاكرة التخزين المؤقت لمسار الملف (Purge Cache) في خلفية إدارة CDN. وإلا، فإن ما يزحف إليه Googlebot سيظل الإصدار القديم المخزن مؤقتًا في عقد CDN، مما يؤدي إلى ظهور طابع زمني جديد في تقرير GSC مع بقاء محتوى القواعد قديمًا.
بالنسبة للمواقع التي تحتوي على نطاقات فرعية متعددة، يمتلك كل نطاق فرعي (مثل blog.example.com و shop.example.com) ملف robots.txt مستقلًا.
عند تشغيل التحديث يدويًا في GSC، يجب التبديل إلى خاصية المورد المقابلة والقيام بالعملية بشكل منفصل.
عند معالجة طلب التحديث اليدوي، لن يقوم Googlebot بتحديث أذونات الزاحف القياسي فحسب، بل سيقوم أيضًا بمزامنة وتحديث قواعد الزحف لـ Googlebot-Image (البحث عن الصور) و Googlebot-Video (البحث عن الفيديو).
إذا تم تعريف مسارات Sitemap متعددة في robots.txt، فبعد نجاح التحديث اليدوي، سيضيف Google مسارات Sitemap هذه إلى زمام الانتظار للمعالجة، ولكنه لن يؤدي بشكل متزامن إلى إعادة الزحف لروابط URL الداخلية لـ Sitemap؛ لا يزال التحديث الفعلي لفهرسة الصفحات بحاجة إلى اتباع تخصيص ميزانية الزحف لكل صفحة.
خلال 24 ساعة، إذا تجاوز عدد الطلبات لنفس خاصية المورد عتبة معينة، سيصبح الزر غير متاح.
يلتزم Googlebot بـ حد 5 عمليات إعادة توجيه.
إذا تمت إعادة توجيه /robots.txt إلى عنوان URL آخر، فسيتبع Googlebot القفزات بحد أقصى 5 مرات.
إذا كانت سلسلة إعادة التوجيه طويلة جدًا أو تشير إلى صفحة 404، سيعتبر Google هذه الحالة “زحف غير مقيد”، أي يسمح افتراضيًا بالوصول إلى جميع محتويات الموقع.
بعد اكتمال التحديث اليدوي، يوصى باستخدام “أداة فحص العناوين” بشكل متكامل.
أدخل عنوان URL محددًا متأثرًا بالقواعد الجديدة في الأداة، وانقر على “اختبار عنوان URL المنشور”.
في بيانات المنطق JSON العائدة، تحقق مما إذا كان حقل “إذن الزحف” يظهر مقابله “محظور بواسطة robots.txt” أو “مسموح به”.
دورة التغيير
بالنسبة لموقع متوسط الحجم يحتوي على 10,000 صفحة، إذا تم حظر دليل معين سابقًا عبر تعليمة Disallow، فبعد تغييرها إلى Allow، يحتاج Googlebot إلى إعادة اكتشاف عناوين URL هذه.
إذا كانت عناوين URL هذه لا تزال موجودة في خرائط مواقع XML، فسيحاول الزاحف زيارتها خلال 48 ساعة؛
أما إذا لم تكن هناك روابط داخلية تشير إلى هذه الصفحات، فستمتد دورة الاكتشاف إلى أكثر من 14 يومًا.
| حجم الموقع ووزنه | نوع تغيير القواعد | الوقت المتوقع لتحديث حالة الفهرس | القيمة المرجعية لتواتر الزحف |
|---|---|---|---|
| مواقع إخبارية كبرى (+1M URL) | إلغاء حظر المسار | 4 ساعات – 24 ساعة | طلبات متعددة في الثانية |
| مواقع شركات عادية (1k-5k URL) | إلغاء حظر المسار | 7 أيام – 21 يومًا | 10-50 طلبًا يوميًا |
| مواقع بأي حجم | إضافة اعتراض Disallow | 24 ساعة – 5 أيام | يعتمد على سرعة انتهاء صلاحية الذاكرة المؤقتة القديمة |
| مواقع جديدة ذات وزن منخفض | إطلاق القواعد | 15 يومًا – 45 يومًا | عدد قليل من الطلبات أسبوعيًا |
عند إزالة تعليمة اعتراض معينة من robots.txt، سيقوم Googlebot بوضع علامة “في انتظار الزحف” على المسارات المتأثرة.
إذا كان الخادم يستجيب ببطء عندما يحاول Googlebot زيارة الصفحات المطلقة حديثًا، أو يعيد عددًا كبيرًا من رموز حالة 503، فسيقوم النظام تلقائيًا بتقليل أولوية الزحف لهذا الموقع، مما يؤدي إلى تأخير نقطة زمن تحديث الفهرس بشكل أكبر.
سيعالج نظام فهرسة Caffeine الداخلي في Google هذه البيانات المزحوفة حديثًا، ويقارنها باللقطات التاريخية.
إذا كان محتوى الصفحة متسقًا مع ما كان عليه عندما تم اعتراضه قبل بضعة أسابيع، فقد يسرع النظام من سرعة الإدراج؛
أما إذا كانت الصفحة محتوى جديد تمامًا، فستحتاج إلى المرور بعملية تقييم جودة كاملة.
يجب التفريق بين “تم الزحف إليه” و “تمت فهرسته”. في تقرير فهرسة صفحات GSC، حتى لو ظهرت الحالة “تم الزحف إليه – لم يتمت فهرسته حاليًا”، فهذا يشير إلى أن التحديث اليدوي لـ robots.txt قد دخل حيز التنفيذ، وأن الزاحف تمكن بنجاح من قراءة محتوى الصفحة. التأخير في هذه المرحلة نابع بشكل أساسي من حسابات خوارزميات Google لجودة الصفحة، وليس من قيود قواعد الزحف.
بالنسبة للصفحات التي كانت في حالة مسموح بها وتحتاج الآن إلى اعتراضها عبر robots.txt، عادةً ما تكون سرعة المعالجة أسرع من “الإطلاق”.
بمجرد أن يكتشف Googlebot في زيارته الدورية التالية أن الطلب مرفوض بواسطة robots.txt، سيسجل هذا التغيير في ذاكرة التخزين المؤقت.
ستختفي عناوين URL المتأثرة من نتائج البحث العادية خلال 3 إلى 7 أيام.
ولكن في بعض الحالات، إذا كانت الروابط الخارجية لا تزال تشير إلى عنوان URL هذا، فقد يحتفظ Google بإدخال فهرس بدون معلومات مقتطفة، ويعرض في نتائج البحث “لا يتوفر وصف لهذه الصفحة بسبب robots.txt”.
تشير هذه الحالة إلى أن robots.txt منع قراءة المحتوى فقط، ولم يمسح وجود عنوان URL هذا تمامًا من قاعدة بيانات الفهرس.
| هدف العملية | آلية التحفيز الفني | منطق سلوك Googlebot | التغذية الراجعة النهائية لقاعدة بيانات الفهرس |
|---|---|---|---|
| استعادة فهرس دليل محذوف بالخطأ | إزالة تعليمة Disallow | إضافة المسار إلى زمام انتظار العناوين المكتشفة حديثًا | إعادة عرض عناوين الصفحات ومقتطفاتها |
| منع عرض دليل حساس | إضافة تعليمة Disallow | التوقف عن إرسال طلبات GET لهذا المسار | إزالة محتوى الصفحة، مع احتمال الاحتفاظ ببديل URL |
| تحسين كفاءة الزحف | تحسين أحرف البدل للمسارات | إعادة توزيع حصة الزحف للمسارات الهامة | زيادة تواتر تحديث اللقطات للصفحات الهامة |
إذا قام الموقع بتعديل robots.txt وفي الوقت نفسه قام بتحديث التعليمات الوصفية للصفحة (مثل meta name=”robots” content=”noindex”)، يرجى الانتباه إلى التعارض المنطقي بينهما.
إذا قام robots.txt باعتراض مسار معين، فلن يتمكن Googlebot من قراءة علامة noindex داخل الصفحة في ذلك المسار.
لإزالة فهرس صفحة ما تمامًا، فإن الطريقة القياسية هي الإبقاء على حالة Allow في robots.txt أولاً، لضمان قدرة Googlebot على قراءة تعليمة noindex داخل الصفحة، وبعد اختفاء الفهرس من نتائج البحث، يتم تنفيذ اعتراض Disallow في robots.txt.
وفقًا للسجلات الفنية لـ Google، عادةً ما تكون دورة انتهاء صلاحية ذاكرة التخزين المؤقت لـ robots.txt هي 24 ساعة. إذا لم يتم إجراء طلب تحديث يدوي في GSC، سيقرر Googlebot وقت الاستخراج القادم بناءً على رأس استجابة Cache-Control الذي أعاده الخادم عند آخر استخراج للملف. إذا ضبط الخادم عمر ذاكرة تخزين مؤقت طويلًا جدًا، فقد يستمر Google في استخدام القواعد القديمة لعدة أيام.
عادةً ما تكون سرعة تحديث فهرسة موارد الصور والفيديو أبطأ من صفحات HTML القياسية.
نظرًا لأن تواتر زحف Googlebot-Image أقل عمومًا من الزاحف الرئيسي، فبعد تعديل قواعد الاعتراض الموجهة لدليل /images/، قد تستغرق الصور في نتائج البحث من 30 إلى 60 يومًا قبل أن تتغير.
التغييرات الفعلية في الفهرس
بعد تعديل robots.txt، يقوم Googlebot افتراضيًا بتحديث ذاكرة التخزين المؤقت المحلية خلال 24 ساعة.
من خلال أداة التقديم في Google Search Console (GSC)، يمكن تقليل تأخير قراءة الملف إلى دقيقة واحدة.
تظهر التغييرات على مستوى الفهرس بخصائص غير متزامنة:
تتوقف طلبات الزحف عادةً خلال 10 دقائق، لكن الحذف التلقائي لعناوين URL من صفحات نتائج البحث (SERP) سيشهد تأخيرًا يتراوح بين 3 إلى 14 يومًا.
بالنسبة للصفحات التي تتجاوز روابطها الخلفية 10,000 رابط، يميل Google إلى الاحتفاظ بـ بدائل الفهرس التي لا تحتوي على معلومات وصفية.
تطور SERP
عندما يقرأ Googlebot تعليمات Disallow الموجهة لمسارات معينة خلال دورة تخزين robots.txt المؤقتة البالغة 24 ساعة، يبدأ التطور في الظهور عادةً خلال 48 إلى 72 ساعة بعد تفعيل التعليمات، وأول ما يختفي هو الوصف التعريفي (Meta Description) للصفحة.
نظرًا لأن Google يتوقف عن زحف هذه الصفحة، لا يمكن لقاعدة بيانات الفهرس الخاصة به الحصول على محتوى علامة <meta name="description"> في مستند HTML.
ويحل محلها بيان فني معياري:
“لا يتوفر وصف لهذا المنتج بسبب ملف robots.txt الخاص بالموقع.”
في ظل غياب البيانات الوصفية الداخلية، ستتحول خوارزمية Google إلى تحليل نص الرابط الخارجي (Anchor Text) للحفاظ على عرض عنوان URL هذا.
وفقًا لوصف وثائق المطورين الرسمية لـ Google (Google Search Central)، إذا كان عنوان URL هذا مرتبطًا من قِبل Amazon أو Wikipedia أو غيرها من المواقع الخارجية ذات الوزن العالي، فسيقوم Google بزحف النصوص التي تستخدمها هذه المواقع الخارجية عند الإشارة إلى هذه الصفحة.
إذا كانت الروابط الخارجية تستخدم بشكل أساسي “انقر هنا” أو “الموقع الرسمي” كنص للرابط، ففي SERP، قد يتغير عنوان هذه الصفحة من الكلمات المحسنة أصلاً إلى هذه الكلمات التي لا معنى لها، أو حتى يعود للعرض كـ رابط URL عارٍ (مثل https://example.com/private-page/).
بالنسبة للصفحات التي تمتلك أكثر من 5,000 رابط خلفي خارجي، فإن احتمالية قيام Google بإزالة بديل SERP الخاص بها منخفضة للغاية.
في هذه المرحلة، عادةً ما تشهد نسبة النقر إلى الظهور (CTR) لهذا الإدخال في نتائج البحث انخفاضًا حادًا يتجاوز غالبًا 85%.
مع مرور الوقت، سيمتد هذا التراجع البصري ليشمل المقتطفات الغنية (Rich Snippets) وعلامات Schema.
ستختفي إضافات التقييم بخمس نجوم، وعرض السعر (Price)، أو حالة المخزون (Availability) وغيرها من البيانات المنظمة تمامًا من SERP خلال 7 أيام.
نظرًا لأن Google لا يمكنه دخول HTML لتنفيذ التحقق الثانوي من JSON-LD أو Microdata، فسيقوم النظام بإزالة هذه المكونات التي كانت تعزز الجاذبية البصرية فعليًا.
بالنسبة لموقع تجارة إلكترونية عابر للحدود يعمل في نيويورك أو لندن، ستتقلص المساحة البصرية التي كانت تسيطر عليها سابقًا في نتائج البحث إلى مجرد عنوان رابط أزرق ممل.
نظرًا لمساحة الشاشة المحدودة على الأجهزة المحمولة، يميل Google إلى إخفاء النتائج ذات كثافة المعلومات المنخفضة للغاية.
إذا كانت الصفحة المحظورة بواسطة robots.txt ذات وزن منخفض في فهرسة الأجهزة المحمولة أولاً (Mobile-First Indexing)، فقد يتم طيها ضمن “عرض المزيد من النتائج” أو دفعها إلى ما بعد الصفحة 5.
من خلال مراقبة 200 موقع حالة، بمجرد أن يعترض robots.txt الزحف، ستنخفض حصة مرات الظهور (Impression Share) لهذا العنوان على الأجهزة المحمولة بنسبة 60% تقريبًا خلال أسبوعين.
حتى لو وجد المستخدم الصفحة من خلال تعليمات دقيقة (مثل site:example.com)، فإن عرضها البصري سيقتصر على إطار هزيل واحد.
ما لم يتم تنفيذ طلب إخفاء إلزامي من خلال “أداة الحذف” في Google Search Console، فقد يظل عنوان URL هذا الذي لا يحتوي إلا على عنوان وتنبيه خطأ موجودًا في SERP لعدة أشهر.
في مناقشات الحالات في المجتمعات التقنية مثل Reddit أو Stack Overflow، غالبًا ما يقدم المطورون ملاحظات تفيد بأن عناوين URL لبيئات الاختبار الخاصة بهم تظل تظهر كبدائل في عمليات بحث معينة طويلة الذيل حتى بعد نصف عام من حظر الزحف.
الجوهر الفني لهذه الظاهرة هو أن Google يعتبر robots.txt بمثابة منظم لتواتر الزحف وليس تعليمة حذف الخصوصية.
| عنصر التغيير البصري | الحالة قبل التعديل | الحالة بعد (7-14 يومًا) | مرجع بيانات التغيير |
|---|---|---|---|
| العنوان (Title) | عنوان مخصص من HTML الصفحة | نص الرابط الخارجي أو مسار URL | انخفاض متوقع في CTR بنسبة +80% |
| الوصف (Snippet) | وصف تعريفي أو استخراج من النص | “لا يتوفر وصف بسبب robots.txt” | تقلص عدد الأحرف إلى حوالي 36 حرفًا ثابتًا |
| المقتطفات الغنية (Schema) | عرض التقييم، السعر، المخزون | اختفاء تام | تقلص المساحة البصرية بنسبة 50% |
| اللقطة (Cache) | توفير مرآة تاريخية كاملة للويب | إزالة الزر أو عرض مؤشر 403 | معدل نجاح الوصول هو 0% |
| فتات الخبز (Breadcrumb) | مسار طبقي منظم | سلسلة URL عارية | فقدان هرمية المسار |
طوال دورة التطور، ستنخفض إحصاءات الزحف التي يراها مشرف الموقع في الخلفية إلى الصفر خلال بضع ساعات، لكن التغير في إدراك المستخدمين في الواجهة الأمامية يحدث ببطء بوحدة الأسابيع.
تغذية التقارير الراجعة
خلال 24 إلى 72 ساعة بعد تعديل ملف robots.txt، ستبدأ بيانات الخلفية في Google Search Console (GSC) بتسجيل وتعكس نتائج تنفيذ تعليمات تقييد الزحف.
في تقرير فهرسة “الصفحات” (Pages)، ستلاحظ انخفاضًا في عدد عناوين URL التي كانت في حالة “تمت الفهرسة”، بينما ستظهر زيادة موازية في قيم فئة التحذير المحددة “تمت الفهرسة، ولكن تم الحظر بواسطة robots.txt”.
هذا التبديل في الحالة عادةً ما يشهد تأخيرًا في البيانات يتراوح بين 3 إلى 5 أيام، لأن تاريخ تقرير GSC يتأخر عادةً يومين عن التاريخ الحالي.
عندما يتم تصنيف كمية كبيرة من الصفحات ضمن فئة “التحذير”، فهذا يشير إلى أن خدمة الزحف (Crawl Service) في Google قد توقفت عن قراءة محتوى HTML لهذه الصفحات، ولكن نظرًا لوجود روابط تشير إلى عناوين URL هذه على الإنترنت، يختار نظام الفهرسة الاحتفاظ بسجلات مساراتها بدلاً من الحذف الفيزيائي.
| وحدة تقرير GSC | نوع تغيير البيانات | الخط الزمني لحدوث التغيير | مرجع مدى تغيير المؤشر |
|---|---|---|---|
| تقرير فهرسة الصفحات | زيادة تحذيرات “تمت الفهرسة ولكن تم الحظر بواسطة robots.txt” | 3 – 7 أيام بعد التعديل | انتقال 100% من عناوين مسار URL المقابلة |
| إحصاءات الزحف (Crawl Stats) | عدد طلبات الزحف لأدلة محددة | 10 دقائق – 24 ساعة بعد التعديل | انخفاض حجم الطلبات بنسبة 95% – 99% |
| أداة فحص العناوين (URL Inspection) | الاختبار المباشر يظهر “تعذر الزحف بسبب robots.txt” | دقيقة واحدة بعد التعديل (تحديث يدوي) | تغير حالة إذن الزحف إلى “فشل” |
| خرائط المواقع (Sitemaps) | خطأ “خريطة الموقع تحتوي على عناوين محظورة بواسطة robots.txt” | 48 – 72 ساعة بعد التعديل | عدد الأخطاء يتطابق مع عدد عناوين URL المحظورة |
في تقرير “إحصاءات الزحف” تحت قائمة “الإعدادات”، من خلال مراقبة المخطط المصنف “حسب الاستجابة”، ستجد أن طلبات الزحف لملف robots.txt ستشهد ذروة قصيرة في التواتر بعد التعديل، ثم تميل للاستقرار.
إذا أعاد الملف رمز الحالة 200 OK وكان تنسيق المحتوى صحيحًا، فسيلتزم Googlebot بدقة بالتعليمات في دورات الزحف التالية.
يمكنك اكتشاف من خلال تصدير جدول بيانات CSV أن عدد طلبات Googlebot-Image أو Googlebot-Video الموجهة للأدلة المحظورة سينخفض إلى الصفر خلال 24 ساعة.
إذا أظهرت إحصاءات الزحف استمرار وجود طلبات لهذه المسارات، فذلك يرجع عادةً إلى محاولة Googlebot معالجة المهام المتبقية التي دخلت زمام انتظار الزحف قبل سريان القواعد، وعادةً لا تتجاوز هذه الطلبات المتبقية 48 ساعة.
توفر أداة فحص العناوين (URL Inspection Tool) أدق البيانات الراجعة لصفحة واحدة.
عندما تدخل عنوان URL مقيدًا وتقوم بتشغيل “اختبار مباشر” (Live Test)، سيعيد النظام أيقونة مؤشر حمراء، توضح بوضوح “الزحف:
فشل” و “السبب: محظور بواسطة robots.txt”.
في علامة تبويب “فهرس Google”، ستجد أن حقل “التغطية” لا يزال يظهر “تمت الفهرسة”؛ هذا الانفصال بين حالة الفهرسة وإذن الزحف هو الوضع الطبيعي خلال فترة سريان robots.txt، وسيستمر حتى يعيد Google حساب قيمة الاحتفاظ بعنوان URL هذا.
بالنسبة للمواقع التي تستخدم خرائط مواقع XML (Sitemaps)، إذا كانت sitemap.xml الخاصة بك تحتوي على عناوين URL تم حظر زحفها بالفعل عبر robots.txt، فسيقوم GSC بتمييزها كحالة “خطأ”.
وذلك لأن جوهر خريطة الموقع هو اقتراح زحف هذه العناوين على Google، بينما robots.txt يمنع الزحف؛ سيؤدي هذا التضارب في التعليمات إلى انخفاض كفاءة الفهرسة.
بناءً على مراقبة اختبارات 500 موقع متوسط وكبير، بعد إصلاح هذا التعارض في التعليمات، تزداد سرعة اكتشاف Google لبقية الصفحات العادية في الموقع بنسبة 15% تقريبًا.
عندما تطلع على تقارير عادية في GSC بخلاف “مشاكل الأمان والإجراءات اليدوية”، حتى لو ألغيت تعليمة الحظر في robots.txt، فإن تحذير “محظور” في تقارير GSC لن يختفي فورًا، بل يحتاج إلى دورة إعادة زحف كاملة (Re-crawl Cycle) لتحديث الحالة.
بعد فقدان دعم الوصف التعريفي وتحسين العنوان، ستنخفض درجات ملاءمة عناوين URL هذه في نتائج البحث بشكل كبير.
- فحص حالة المضيف في تقرير إحصاءات الزحف: تحقق من حالة استخراج
robots.txtفي إعدادات GSC، وتأكد من أن معدل نجاح الاستخراج خلال آخر 24 ساعة هو 100%. إذا ظهرت أخطاء 403 أو 5xx، فسيعود Google لاستخدام آخر نسخة ناجحة مخزنة مؤقتًا، مما يؤدي إلى فشل القواعد الجديدة. - تصدير سجلات الزحف للتحقق من المسارات: من خلال بيانات الزحف التفصيلية المصدرة من GSC، يمكن التأكد مما إذا كان User-agent لـ Googlebot قد تعرف بدقة على التعليمات الموجهة. على سبيل المثال، إذا قمت بحظر
Googlebot-Imageفقط، فيجب أن تظل طلبات زاحف الويب طبيعية في إحصاءات الزحف، بينما تنخفض طلبات زاحف الصور إلى رقم آحاد. - مراقبة مدة بقاء بدائل الفهرس: تتبع عناوين URL التي تحمل علامات تحذير في تقرير “الصفحات”؛ إذا لم تنتقل هذه العناوين بعد 30 يومًا من فئة التحذير إلى فئة “لم يتمت فهرسته”، فعادةً ما يشير ذلك إلى أن هذه الصفحات تمتلك أوزان روابط خارجية عالية جدًا، ولا يمكن لـ
robots.txtوحده إخراجها من قاعدة بيانات الفهرس.
لا ينبغي للمطورين توقع رؤية تغييرات في الأرقام في التقارير الملخصة خلال 10 دقائق من تعديل الملف.
على العكس من ذلك، يجب تركيز الانتباه على التغييرات اللحظية في “إحصاءات الزحف” والاختبارات الفردية في “فحص العناوين”.
