429 Too Many Requests: تحديد المعدل والزواحف
429 Too Many Requests يعني أن العميل بلغ حد المعدل؛ ويعامله Googlebot كخطأ في الخادم فيبطّئ زحفه.
429 Too Many Requests يعني أن العميل أرسل طلبات أكثر مما يسمح به الخادم في مدة معينة: بلغ حد المعدل (rate limit). هكذا تقاوم واجهات API وشبكات CDN وأدوات الأمان الحمل الزائد والكشط ومحاولات القوة الغاشمة، وهو رمز 4xx الوحيد الذي يعدّه Googlebot سببًا للتباطؤ لا دليلًا على أن الصفحة غير موجودة.
التعريف
الرمز 429 ليس في مواصفة HTTP الأساسية؛ أضافه RFC 6585، القسم 4 عام 2012. وينبغي أن يشرح الرد الحالة، وقد يتضمن ترويسة Retry-After تحدد مدة الانتظار بالثواني أو كتاريخ. ولا يحدد الـ RFC عمدًا كيف يتعرف الخادم على العميل أو يحسب الطلبات (لكل IP أو حساب أو مفتاح API)، ويقول إن ردود 429 يجب ألا تُخزَّن في ذواكر التخزين المؤقت.
كيف يتعامل Googlebot مع 429
تقول وثائق Google عن رموز حالة HTTP إن Googlebot يعدّ 429 إشارة إلى أن الخادم مثقل، كما يعامل خطأ الخادم. فيتباطأ الزحف. وتبقى الروابط المفهرسة في الفهرس فترة، لكن الروابط التي تواصل إعادة 429 تُسقط في النهاية. وإذا أعاد robots.txt نفسه الرمز 429، فإن Google تعامل الموقع كله مؤقتًا كأنه محظور.
وهذا يجعل 429 فرملة طوارئ مشروعة. يقترح دليل Google لتقليل معدل الزحف إعادة 500 أو 503 أو 429 عندما يثقل Googlebot خادمك، لكن لفترة قصيرة فقط، بحدود ساعات أو يوم أو يومين. وقد أوقفت Google أداة تحديد معدل الزحف في Search Console في يناير 2024، فصارت رموز الحالة هي الرافعة الرئيسية الآن.
رموز 429 غير مقصودة
المشكلة الأكثر شيوعًا هي حد معدل يوقع الزواحف التي تريدها. ومن مصادره المعتادة:
- قواعد تحديد المعدل في CDN أو WAF بعتبات منخفضة.
- إضافات الأمان التي تخنق أي عميل يرسل طلبات كثيرة.
- حدود مرتبطة بعنوان IP خلف بروكسي أو CDN، حيث يبدو أن كل الزيارات قادمة من عدد قليل من العناوين.
- باقات استضافة بسقوف للطلبات.
كيف تصلحه
لأصحاب المواقع
- افحص تقرير إحصاءات الزحف في Search Console وسجلات CDN أو جدار الحماية بحثًا عن 429 قُدّمت إلى Googlebot أو Bingbot.
- ارفع العتبات أو استثنِ زواحف محركات البحث الموثَّقة؛ وتحقق منها بالبحث العكسي في DNS أو بنطاقات IP المنشورة، لا بـ user-agent.
- لا تستخدم 429 كحجب طويل الأمد. ولإبعاد روبوت استخدم robots.txt أو 403.
للمطورين
يرد limit_req في Nginx بالرمز 503 افتراضيًا؛ اضبطه على 429 كي يعرف العملاء أنه حد معدل لا انقطاع:
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
server {
location / {
limit_req zone=perip burst=20 nodelay;
limit_req_status 429;
}
}
وعندما يستدعي كودك واجهة API تعيد 429، تراجع: التزم بـ Retry-After إن وُجدت، وإلا أعد المحاولة بتأخيرات متزايدة مع قدر من العشوائية (jitter).
كيف تتحقق
تُظهر أداة فحص حالة HTTP ما إذا كانت الروابط تعيد 429 لعميل خارجي، وتكشف أداة فحص ترويسات HTTP قيمة Retry-After. وقارنه بـ 503، وهو رمز الخادم غير المتاح للجميع.
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 120
{"error":"Rate limit exceeded. Try again in 2 minutes."} الأسئلة الشائعة
هل يضر الخطأ 429 بالسيو؟
لفترة وجيزة يبطّئ Googlebot فقط. أما إذا واصلت الروابط إعادة 429 مدة أطول، فستُسقطها Google من الفهرس في النهاية، لذلك استثنِ الزواحف الموثَّقة من الحدود المتشددة.
كيف أمنع Googlebot من الاصطدام بحدود المعدل عندي؟
اسمح لعناوين IP الموثَّقة لـ Googlebot بتجاوز قواعد تحديد المعدل، أو ارفع العتبات. فـ Googlebot يضبط معدل زحفه أصلًا بحسب سرعة استجابة خادمك وموثوقيتها.
هل أستخدم 429 أم 503 عندما يكون الخادم مثقلًا؟
استخدم 429 عندما يتجاوز عميل بعينه حصته، و503 عندما تكون الخدمة كلها غير متاحة مؤقتًا. وتعدّ Google كليهما إشارة إلى التباطؤ.