429 طلبات كثيرة

الخلاصة — يعني 429 Too Many Requests أن خادمك أخبر الزائر أو الروبوت: «أنت تطلب صفحات كثيرة بسرعة شديدة — أبطئ». وهذا هو تحديد المعدل. والخبر الجيد بالنسبة إلى SEO أن 429 هو الخطأ الوحيد في عائلته الذي تتعامل معه Google بلطف: بدلاً من إسقاط صفحاتك، يخفف Googlebot الزحف لفترة. ولا يصبح مشكلة إلا إذا واصل خادمك إرسال 429 أياماً متتالية.

ماذا يقول 429 فعلياً

كلما طلب متصفح أو سكربت أو زاحف محرك بحث صفحة من خادمك، أجاب الخادم برمز حالة. يعني 200 «ها هي الصفحة». أما 429 فيعني «أرسلت طلبات كثيرة في نافذة قصيرة، لذلك لن أجيب عن هذا الطلب — عد لاحقاً».

تستخدم الخوادم 429 لحماية نفسها عمداً. فإذا كان زائر واحد (أو روبوت واحد) يضغط على الموقع بسرعة تكفي لإبطائه على الجميع، فإعادة 429 هي طريقة الخادم للقول: توقف عن ذلك قليلاً. وتتضمن استجابة 429 الجيدة أيضاً ترويسة Retry-After — ملاحظة تخبر العميل عدد الثواني التي ينتظرها قبل إعادة المحاولة. Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

لماذا يعد 429 الخطأ «اللّطيف» بالنسبة إلى SEO

هذه هي المفاجأة. يقع 429 في مجموعة «خطأ العميل 4xx»، بجوار رموز مثل 403 Forbidden و404 Not Found. وهذان الرمزان خبر سيئ إذا استمرت Google في رؤيتهما — إذ تسقط Google تلك الصفحات من البحث في النهاية.

429 هو الاستثناء. تقرأ Google 429 على أنه الخادم مشغول، أبطئ، بالطريقة نفسها التي تقرأ بها خطأ خادم 503 أو 500. لذلك، بدلاً من إزالة صفحاتك، يزحف Googlebot إلى موقعك ببطء لفترة. وتوصي Google فعلياً بـ429 كطريقة صحيحة لإبطاء الزاحف، وتحذر تحديداً من استخدام 403 أو 404 لهذا الغرض. Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

متى يصبح 429 مشكلة

429 المتقطع طبيعي تماماً ويُصلح نفسه — فبمجرد أن يتوقف خادمك عن إرساله، تسرّع Google الزحف من تلقاء نفسها. لا تحتاج إلى طلب ذلك.

الخطر هو استمرار 429. فإذا استمر Googlebot في الحصول على 429 على الصفحات نفسها أكثر من يوم أو يومين، فقد تبدأ Google بإسقاط تلك الصفحات من فهرسها — لأن ما يراه Google هو موقع متعطل وغير متاح أياماً. لذا فـ429 أداة قصيرة الأجل، لا إعداد دائم.

ماذا تفعل حياله

• إذا لم تكن تقصد إرسال أخطاء 429 (وظهر ذلك في Google Search Console أو أداة الزحف فجأة)، فهناك شيء يحدد المعدل بصرامة مفرطة — غالباً إضافة أمنية أو جدار حماية (WAF) أو استضافتك/CDN. اعثر عليه وخفف الحد حتى يتوقف عن حظر محركات البحث الحقيقية.
• إذا كنت تقصد إرسالها — مثلاً لأن الخادم تحت حمل ثقيل — فلا مشكلة، لكن حدده زمنياً وأضف ترويسة Retry-After. أوقفه خلال يوم أو يومين.

هل تريد طريقة إعداد الخادم، والصياغة الدقيقة لـGoogle، والخرافات الشائعة؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — 429 هو رمز 4xx الوحيد الذي تتعامل معه Google مثل 5xx: عندما تواجه عدداً مهماً من استجابات 500/503/429، تقرأ ذلك كإشارة إلى حمل الخادم وتخنق معدل زحف Googlebot على مستوى اسم المضيف كله بدلاً من إزالة المحتوى. وهو الرمز الوحيد الذي تؤيده Google لإبطاء الزاحف — لا 403 ولا 404. وتعطي وثائق Google إرشاد الاستخدام الطارئ «بضع ساعات أو يوم إلى يومين» — لا نافذة أمان مضمونة؛ فاستمرار 429 على عناوين URL نفسها يعرضها للإسقاط من الفهرس، ويبدأ الخنق في الارتفاع مجدداً (ليس بالضرورة فوراً أو كاملاً) عندما ينخفض حجم الأخطاء. ويقول RFC 6585 إن استجابة 429 ينبغي أن تشرح الحالة ويجوز أن تتضمن Retry-After — وإرسالها ممارسة موصى بها لا متطلب امتثال. قيّد الحد على حركة المرور الصحيحة وتحقق من هوية الزاحف قبل كتابة الاستثناءات.

ما هو 429 على مستوى البروتوكول

يورد MDN التعريف البروتوكولي التالي، محفوظاً بلغة المصدر: وفق المواصفة، تقول MDN: “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (الترجمة العربية) «يشير رمز حالة خطأ العميل HTTP 429 Too Many Requests إلى أن العميل أرسل طلبات كثيرة خلال مدة معينة؛ وتُسمى آلية مطالبة العميل بإبطاء معدل الطلبات عادةً تحديد المعدل.» Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

يحدد RFC 6585 §4 الأمر بدقة أكبر من معظم الملخصات. ينبغي أن تشرح استجابة 429 الحالة، ويجوز أن تتضمن ترويسة Retry-After بعدد ثوانٍ محدد (ويسمح RFC 9110 أيضاً بتاريخ HTTP) ينتظره العميل قبل إعادة المحاولة — فهي ممارسة موصى بها لا متطلب امتثال. ولا تحدد المواصفة كيفية تعريف العميل أو كيفية عد الطلبات؛ فهذا متروك تماماً للجهة التي أصدرت الاستجابة (لكل IP أو جلسة أو مفتاح API أو مورد — سياسة تنفيذ لا بروتوكول). وهناك قاعدة يسهل تفويتها: يقول RFC 6585 إن استجابة 429 يجب ألا تخزنها ذاكرة مؤقتة. فإذا رأيت 429 يبدو مخزناً أو معاد التشغيل مع أصل سليم، فالمشكلة في وسيط (CDN أو proxy)، لا في أن الأصل قرر تحديدك من جديد.

يرد دليل رموز حالة HTTP لدي هذا المعنى بصياغة مصدرية محفوظة. أصفه عادةً ببساطة في دليلي عن رموز الحالة HTTP وتأثيرها في SEO: 429 هو “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” (الترجمة العربية) «شكل من تحديد المعدل لحماية الخادم لأن العميل أرسل طلبات كثيرة بسرعة كبيرة.» وهو اسمياً خطأ من جهة العميل — فقد أخطأ العميل بطلب الكثير. لكن هنا تحديداً تنفصل قصة SEO عن المواصفة.

الاستثناء الوحيد بين رموز 4xx

أهم حقيقة في هذه الصفحة: لا تتعامل Google مع 429 مثل بقية عائلة 4xx. كتب Gary Illyes منشوراً كاملاً في مدونة Google Search Central عن ذلك في فبراير 2023، لأن مواقع وشبكات CDN كثيرة كانت تسيء استخدام صفحات غير موجودة لخنق Googlebot، فاضطرت Google إلى مطالبتها بالتوقف.

القاعدة التي نقلها Illyes والصياغة المقابلة لدى Google محفوظتان بلغة المصدر: قاعدته هي: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (الترجمة العربية) «هذه الحالة الاستثنائية هي 429، أي «طلبات كثيرة». إنها رسالة مباشرة إلى الروبوت المنضبط، ومنها Googlebot، كي يخفف الضغط عن الخادم.» وفي الجهة المقابلة، تقول مرجعية رموز الحالة لدى Google: “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (الترجمة العربية) «لا تستخدم رموز الحالة 401 و403 لتحديد معدل الزحف؛ فأخطاء 4xx، باستثناء 429، لا تؤثر في معدل الزحف.»

تلخص Google الفرق: في الوقت الذي تؤدي فيه 403 و404 إلى إزالة المحتوى من البحث، تمنحك 429 إبطاءً مؤقتاً. وتضعها Google حرفياً مع أخطاء الخادم: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (الترجمة العربية) «تتعامل زواحف Google مع رمز الحالة 429 بوصفه إشارة إلى أن الخادم محمّل، وتعدّه خطأ من أخطاء الخادم.» Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: 2026-07-14 Google: Reduce Google crawl rate

وهذا ما يجعل 429 الشقيق المفيد لـ503 Service Unavailable (إشارة الصيانة/عدم التوفر المؤقت التقليدية) — والعكس تماماً لـ403 Forbidden، وهو الأداة الخاطئة لتحديد المعدل رغم أن كثيراً من جدران الحماية تضبطه افتراضياً.

أثر معدل الزحف على مستوى اسم المضيف — مع عتبة

توضح Google النطاق والعتبة في الاقتباس التالي: يختلط نطاقان مختلفان هنا ويستحقان الفصل. طريقة عدّ حد المعدل ومفتاحه — لكل IP أو جلسة أو مفتاح API أو مورد أو خادم — سياستك أنت؛ فمواصفة HTTP لا تحددها. وما تفعله Google بالأخطاء التي تلاحظها سلوك موثق منفصل، مشروط بالحجم لا باستجابة واحدة: “Google’s crawling infrastructure reduces your site’s crawling rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” (الترجمة العربية) «تخفض بنية زحف Google معدل زحف موقعك عندما تواجه عدداً مهماً من العناوين التي تعيد رموز حالة HTTP 500 أو 503 أو 429.» وعند بلوغ العتبة: “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.” (الترجمة العربية) «يؤثر معدل الزحف المخفّض في اسم مضيف موقعك كله، سواء زحف العناوين التي تعيد الأخطاء أو العناوين التي تعيد المحتوى.»

بعبارة أخرى، إذا أعدت 429 لمجموعة من الصفحات (مثل مسار API ثقيل) بحجم حقيقي، فسيبطئ Googlebot زحفه إلى اسم المضيف كله — بما في ذلك الصفحات التي ما زالت تعيد 200. وهذا هو الأثر المقصود عادةً عند هدفك تقليل الحمل الكلي. لكن 429 واحداً معزولاً في مسار واحد لا يثبت وحده ذلك الأثر على كامل اسم المضيف — فصياغة Google مقيدة بـ«عدد مهم» من الاستجابات، لا بأي استجابة مفردة. Evidence for this claim When Google encounters a significant number of 500, 503, or 429 responses, its documented crawl-rate reduction affects the whole hostname, including error URLs and URLs still returning content; one isolated 429 does not establish that site-wide effect. Scope: hostname crawl-load incidents Confidence: high · Verified: 2026-07-16 Reduce Google crawl rate

إرشاد اليوم أو اليومين — متى يصبح 429 محفوفاً بالمخاطر

يصف مصدر Google نافذة الاستخدام الطارئ، مع إبقاء الاقتباس كما هو: 429 إشارة قصيرة الأجل، وتقدم Google إرشاداً ملموساً للاستخدام الطارئ — لا نافذة أمان مضمونة ولا حداً قاطعاً. وتقول وثائق «خفض معدل الزحف»: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (الترجمة العربية) «إذا احتجت إلى خفض معدل الزحف على وجه السرعة لفترة قصيرة (بضع ساعات أو يوم إلى يومين مثلاً)، فأعد رمز حالة HTTP 500 أو 503 أو 429 بدلاً من 200 لطلبات الزحف.»

توضح وثائق Google مخاطر الاستمرار، والاقتباسات المصدرية محفوظة: تجاوز هذه المدة يدخلك منطقة أخطر، مع أن Google تصوغها كاحتمال لا وعد: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” (الترجمة العربية) «لا نوصي بفعل ذلك فترة طويلة (أكثر من يوم إلى يومين) لأنه قد يؤثر سلباً في ظهور موقعك في منتجات Google؛ وإذا رصد Googlebot هذه الرموز على العنوان نفسه عدة أيام، فقد يُسقط العنوان من فهرس Google.» وتقول مرجعية رموز الحالة الشيء نفسه عن 5xx و429 معاً: “already indexed URLs are preserved in the index, but eventually dropped.” (الترجمة العربية) «تُحفظ العناوين المفهرسة بالفعل في الفهرس، لكنها تُسقط في النهاية.»

نموذج المخاطر بصياغة صادقة: يطابق 429 القصير النافذة التي توصي بها Google للاستخدام الطارئ؛ أما استمرار 429 على العناوين نفسها عدة أيام فهو حيث تتحول لغة Google إلى «may» و«eventually dropped» — خطر موثق لا نتيجة مضمونة في أي اتجاه. وهي الديناميكية نفسها لخطأ 503 المطول.

يتعافى معدل الزحف تلقائياً

تؤكد Google أن التعافي يبدأ من تلقاء نفسه، مع حفظ الصياغة المصدرية: الجانب المطمئن هو أنه لا توجد علامة عقوبة تلاحق موقعك. عندما تهدأ الأخطاء، تقول Google: “the crawl rate will automatically start increasing again.” (الترجمة العربية) «سيبدأ معدل الزحف تلقائياً في الارتفاع من جديد.» لا تقدم طلباً ولا تعيد طلب شيء. لكن انتبه إلى الصياغة الدقيقة: تقول Google «يبدأ بالارتفاع»، لا “instantly returns to your prior rate.” (الترجمة العربية) «لا يعود فوراً إلى معدلك السابق». تعامل مع التعافي كاتجاه موثق بلا جدول زمني ثابت أو نقطة نهاية مضمونة، لا كاتفاقية مستوى خدمة.

تقارن Google بين التعافي وتقليل الزحف الدائم؛ الاقتباس محفوظ: (قارن ذلك بالمشكلة المعاكسة — أن تريد من Google أن تزحف إلى موقعك أقل بصورة دائمة. إذا لم يكن إرسال الأخطاء ممكناً، تقول Google: “file a special request to report a problem with unusually high crawl rate” (الترجمة العربية) «قدّم طلباً خاصاً للإبلاغ عن مشكلة في معدل زحف مرتفع على نحو غير معتاد.» — مسار يدوي قد يستغرق أياماً وليس مضموناً. لا يوجد هذا العائق أمام التعافي.)

كيف تتعامل Bing مع 429

يُقال على نطاق واسع إن Bingbot يتصرف بالمثل — إشارات 429/500/503 للحمل الزائد وتراجع Bingbot — مع أنني لم أتمكن من تأكيد صياغة حالية مستقلاً في صفحات مساعدة Bing نفسها في هذه الجولة (فهي تطبيقات SPA تعتمد JavaScript ولم تنتج نصاً ثابتاً قابلاً للجلب). تعامل مع ادعاء التكافؤ كتقرير من المجال لا كشيء تحقق من وثائق Bing الحالية. وما تؤكده Bing في إرشاداتها التاريخية هما وسيلتا تحكم استباقيتان لا توفرهما Google بالصورة نفسها:

• Crawl Control في Bing Webmaster Tools، وهي شبكة طلبات في الثانية تضبط بها سرعة Bingbot حسب ساعة اليوم.
• توجيه crawl-delay في robots.txt. توثق إرشادات Bing الحالية قيماً من 1 إلى 20 ثانية. وهذا خاص بـBing، ولا يخنق Googlebot.

لذلك يمكنك في Bing تحديد المعدل استباقياً باستخدام crawl-delay أو Crawl Control بدلاً من استخدام رموز الحالة تفاعلياً. (أوقفت Google منزلقها اليدوي لمعدل الزحف في 2024، وتعتمد الآن بالكامل على استجابات خادمك.)

متى ترسل 429 عمداً

أسباب مشروعة لإعادة أخطاء 429 عن قصد:

• حمل خادم طارئ — ارتفاع في الحركة أو ترحيل فاشل أو انقطاع تحتاج فيه إلى إبطاء Googlebot الآن لبضع ساعات.
• حماية API ونقاط النهاية غير HTML من إساءة الروبوتات — فزواحف البحث والزواحف التجارية (Ahrefs وScreaming Frog) والكاشطات كلها تصطدم بحدود معدلات تهدف إلى منع الإساءة.

ما الذي لا يستخدم 429 له: حظر الروبوتات التي لا تريدها نهائياً. إذا لم ترد زحف شيء قط، فهذه مهمة منع في robots.txt لا 429. وإذا أردت إبقاء الصفحة خارج الفهرس، فهذه وظيفة noindex. 429 يعني «لاحقاً»، لا «أبداً».

أخطاء 429 غير المقصودة — الأسباب المعتادة

عندما تظهر أخطاء 429 في تقرير Page Indexing أو Crawl Stats في GSC ولم تضعها أنت، فالمصدر غالباً أحد هذه الأسباب — ولا أعرف دليلاً جيداً على ترتيب عالمي لمدى شيوعها، فتعامل معها كمرشحين للتحقق لا كتشخيص:

• قواعد WAF/جدار الحماية التي تخطئ في نطاقات IP للزواحف المشروعة.
• حدود المعدل الافتراضية في الاستضافة المشتركة أو CDN الضيقة أكثر من اللازم لزحف حقيقي.
• أدوات إدارة الروبوتات التي تصنف Googlebot أو Bingbot خطأً كحركة مسيئة.
• وسيط تحديد معدل عدواني مخصص لإساءة استخدام API ويلتقط زواحفك.

قبل تغيير عتبة أو كتابة قاعدة تستثني روبوتات البحث الحقيقية، أثبت المصدر أولاً — لا تخمن أي طبقة تملك الاستجابة. اجلب ترويسات الاستجابة الخام، وأسطر سجل الطلب الدقيقة (لا ملخص لوحة)، ومعرّف القاعدة أو منطقة تحديد المعدل التي عملت، ومفتاح العميل الذي عُدّ ضده (IP أو جلسة أو API key)، والمسار، وموقع CDN POP/الحافة، والنافذة الزمنية. يخبرك هذا المزيج أي طبقة أصدرت 429 وما الذي كانت تعده — عندها فقط يصبح تخفيف الحد أو إضافة استثناء منطقياً. تحقق من هوية الزاحف عبر DNS العكسي + الأمامي (طريقة Google الرسمية)، لا سلسلة user-agent وحدها — فسلاسل «Googlebot» المنتحلة شائعة. تعرض علامة Scripts الأوامر الدقيقة.

النسخة القصيرة من دليل العمل

1. استخدم 429 أو 503 مع Retry-After لإبطاء الزاحف — لا 403 ولا 404.
2. أبقه ساعات أو يوماً إلى يومين — فبعد ذلك قد تُسقط العناوين.
3. تذكر أن الخنق على مستوى اسم المضيف كله، وأنه يتعافى تلقائياً عند توقف الأخطاء.
4. قيّد الحد على حركة المرور الصحيحة وتحقق من هوية الزاحف قبل استثناء الروبوتات.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

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

• 429 Too Many Requests يعني أن الخادم يخبر العميل (متصفحاً أو برنامجاً أو زاحفاً) بأنه أرسل طلبات كثيرة بسرعة — أي «تحديد المعدل». وهو اسمياً خطأ من فئة 4xx جهة العميل.
• على مستوى البروتوكول: يقول RFC 6585 إن استجابة 429 ينبغي أن تشرح الحالة ويجوز أن تتضمن Retry-After — موصى به لا إلزامي. كما يجب ألا تخزنها ذاكرة مؤقتة؛ فـ429 المخزنة/المعاد تشغيلها عطل في وسيط لا في الأصل. وكيفية عد الحد أو اختيار مفتاحه (IP أو جلسة أو API أو مورد) سياستك أنت، ولا تحددها المواصفة.
• الاستثناء الوحيد بين 4xx: تتعامل Google مع 429 كخطأ خادم 5xx، لا مثل 403/404. تقرؤه “server overloaded, slow down” (الترجمة العربية) «الخادم محمل، أبطئ» وتخنق معدل الزحف بدلاً من إزالة المحتوى.
• تؤيد Google 429 (و500/503) لإبطاء الزواحف، وليس 403 أو 404. كتب Gary Illyes منشوراً في 2023 يطلب تحديداً من المواقع وشبكات CDN التوقف عن استخدام 404 لخنق Googlebot.
• الخنق على مستوى اسم المضيف وفوق عتبة: تربط صياغة Google أثر اسم المضيف كله بمواجهة «عدد مهم» من استجابات 500/503/429، لا 429 واحدة. وبعد العتبة تُزحف الصفحات التي ما زالت تعيد 200 بوتيرة أقل أيضاً.
• إرشاد اليوم أو اليومين لا حد قاطع: تقدم وثائق Google للاستخدام الطارئ «بضع ساعات أو يوم إلى يومين». واستمرار 429 على العناوين نفسها عدة أيام يعرضها للإسقاط من الفهرس — «قد» و«في النهاية»، لا ضماناً — على نحو يشبه 503 المطول.
• التعافي اتجاه لا لحظة فورية: أوقف إرسال 429 فتقول Google إن معدل الزحف «يبدأ بالارتفاع مجدداً» — بلا طلب جديد ولا عقوبة باقية، لكن أيضاً بلا وعد بمعدل فوري أو مستعاد بالكامل في جدول ثابت.
• إعادة المحاولة من جهة العميل: احترم Retry-After الصالحة إن وجدت؛ وعند غيابها لا يفرض RFC معادلة، فاستخدم تراجعاً محدوداً مع jitter، وحدد المحاولات، وافحص idempotency قبل تكرار طلب غير قابل للتكرار بأمان.
• قيّد الحد على حركة المرور الصحيحة وتحقق من هوية الزاحف (DNS عكسي + أمامي) قبل استثناء الروبوتات.
• يُقال على نطاق واسع إن Bing يتراجع أمام 429 بالمثل، لكن لم يؤكد ذلك مستقلاً مقابل وثائق Bing الحالية في هذه الجولة؛ وتؤكد إرشاداته التاريخية crawl-delay وشبكة Crawl Control كبدائل استباقية.
• 429 ≠ حظر: معناها «لاحقاً» لا «أبداً». استخدم robots.txt لإبعاد الروبوتات وnoindex لإخراج صفحة من الفهرس.

الوثائق الرسمية

وثائق المصادر الأولية من محركات البحث ومن مواصفة HTTP.

مراجع Google الرسمية كما وردت في المصدر: Google

• لا تستخدم 403 أو 404 لتحديد المعدل — منشور Gary Illyes في فبراير 2023؛ البيان المرجعي بأن 429 هو الاستثناء وأن 403/404 أداتان خاطئتان.
• خفض معدل زحف Google — إرشاد «إعادة 500 أو 503 أو 429»، ونافذة اليوم إلى اليومين، والخنق على مستوى اسم المضيف، والتعافي التلقائي.
• رموز حالة HTTP وأخطاء الشبكة وDNS — كيفية تعامل Google مع كل رمز؛ وتجميع 429 مع أخطاء الخادم (ومتاح أيضاً على المسار الأقدم search/docs/crawling-indexing/http-network-errors).
• خفض معدل زحف Google — مسار الطلب الخاص — المسار اليدوي «الإبلاغ عن مشكلة في معدل زحف مرتفع على نحو غير معتاد» عندما يتعذر إرسال الأخطاء.

مراجع Bing/Microsoft كما وردت في المصدر: Bing / Microsoft

• التحكم في الزحف — مجدول طلبات Bingbot في الثانية داخل Bing Webmaster Tools.
• إرشادات Bingbot — إرشاد Bing Webmaster الحالي لـcrawl-delay (من 1 إلى 20 ثانية).

مرجع مواصفة HTTP كما ورد في المصدر: مواصفة HTTP

• MDN — 429 طلبات كثيرة جداً — تعريف البروتوكول وRetry-After وأساسيات تحديد المعدل.

اقتباسات من المصدر

تصريحات مسجلة من Google وBing ومواصفة HTTP. كل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — Gary Illyes، «لا تستخدم أخطاء 403 أو 404 لتحديد المعدل» (فبراير 2023)

الاقتباسات الرسمية من Illyes محفوظة بلغة المصدر مع روابطها:

• “Over the last few months we noticed an uptick in website owners and some content delivery networks (CDNs) attempting to use 404 and other 4xx client errors (but not 429) to attempt to reduce Googlebot’s crawl rate.” (الترجمة العربية) «لاحظنا خلال الأشهر القليلة الماضية زيادة في مالكي المواقع وشبكات توصيل المحتوى التي تحاول استخدام أخطاء العميل 404 وغيرها من أخطاء 4xx، لا 429، لخفض معدل زحف Googlebot.» «انتقل إلى الاقتباس» (الترجمة العربية) «انتقل إلى الاقتباس.»
• “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” (الترجمة العربية) «الاستثناء الوحيد هو 429، الذي يعني «طلبات كثيرة». وهذه إشارة واضحة لأي روبوت حسن السلوك، ومنها Googlebot، إلى أنه ينبغي أن يبطئ لأنه يحمّل الخادم فوق طاقته.» انتقل إلى الاقتباس
• “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (الترجمة العربية) «ستؤدي جميع رموز حالة HTTP من فئة 4xx، باستثناء 429، إلى إزالة المحتوى من بحث Google.» «انتقل إلى الاقتباس» (الترجمة العربية) «انتقل إلى الاقتباس.»
• “Use Search Console to temporarily reduce crawl rate. Return a 500, 503, or 429 HTTP status code to Googlebot when it’s crawling too fast.” (الترجمة العربية) «استخدم Search Console لخفض معدل الزحف مؤقتاً؛ وأعد رمز حالة HTTP 500 أو 503 أو 429 إلى Googlebot عندما يزحف بسرعة كبيرة.» انتقل إلى الاقتباس

Google — تقليل معدل الزحف / مرجع رموز الحالة

اقتباسات إرشادات Google محفوظة بلغة المصدر:

• “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.” (الترجمة العربية) «إذا احتجت إلى خفض معدل الزحف على وجه السرعة لفترة قصيرة (بضع ساعات أو يوم إلى يومين مثلاً)، فأعد رمز حالة HTTP 500 أو 503 أو 429 بدلاً من 200 لطلبات الزحف.» «انتقل إلى الاقتباس» (الترجمة العربية) «انتقل إلى الاقتباس.»
• “The reduced crawl rate affects the whole hostname of your site… Once the number of these errors is reduced, the crawl rate will automatically start increasing again.” (الترجمة العربية) «يؤثر معدل الزحف المخفّض في اسم مضيف موقعك كله؛ وبمجرد انخفاض عدد هذه الأخطاء، سيبدأ معدل الزحف تلقائياً في الارتفاع من جديد.» انتقل إلى الاقتباس
• “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days)… the URL may be dropped from Google’s index.” (الترجمة العربية) «لا نوصي بفعل ذلك فترة طويلة (أكثر من يوم إلى يومين) لأنه قد يؤثر سلباً في ظهور موقعك في منتجات Google؛ وإذا رصد Googlebot هذه الرموز على العنوان نفسه عدة أيام، فقد يُسقط العنوان من فهرس Google.» انتقل إلى الاقتباس
• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (الترجمة العربية) «تتعامل زواحف Google مع رمز الحالة 429 بوصفه إشارة إلى أن الخادم محمّل، وتعدّه خطأ من أخطاء الخادم.» انتقل إلى الاقتباس
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (الترجمة العربية) «لا تستخدم رموز الحالة 401 و403 لتحديد معدل الزحف؛ فأخطاء 4xx، باستثناء 429، لا تؤثر في معدل الزحف.» انتقل إلى الاقتباس

MDN — التعريف البروتوكولي

اقتباس MDN محفوظ بلغة المصدر:

• “The HTTP 429 Too Many Requests client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” (الترجمة العربية) «يشير رمز حالة خطأ العميل HTTP 429 Too Many Requests إلى أن العميل أرسل طلبات كثيرة خلال مدة معينة؛ وتُسمى آلية مطالبة العميل بإبطاء معدل الطلبات عادةً تحديد المعدل.» انتقل إلى الاقتباس

Bing — إرشادات Webmaster الحالية

• توثق إرشادات Bingbot قيماً لـcrawl-delay من 1 إلى 20 ثانية. تعامل معها كإرشاد خاص بـBing لا كخنق عام للزواحف.

تأييد من المجال لبيان Google

• غطت Search Engine Land وSearch Engine Roundtable وSearch Engine Journal منشور Illyes في فبراير 2023 حرفياً، وكلها تقدم 429 بوصفه «الاستثناء الوحيد». هذه تغطيات صحافة تجارية للمنشور نفسه؛ المصدر الأولي هو منشور Illyes المقتبس أعلاه.

أرسل 429 سليماً — مع Retry-After

أهم جزء في 429 حسن السلوك هو ترويسة Retry-After. فهي تخبر أي عميل ملتزم — بما في ذلك Googlebot — كم ينتظر. وتقبل إما عدداً من الثواني أو تاريخ HTTP:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: text/html

<html><body>Too many requests. Please retry later.</body></html>

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 01 Jul 2026 12:00:00 GMT

حذف Retry-After لا يخرق الامتثال، لكن تضمينها ممارسة جيدة ويمنح الزواحف إشارة تراجع محددة.

nginx — تحديد المعدل الذي يعيد 429

يعيد nginx افتراضياً 503 مع limit_req. وللدلالة الملائمة للزواحف، غيّرها إلى 429 وأضف ترويسة Retry-After. يسمح هذا المثال بـ10 طلبات في الثانية لكل IP مع دفعة صغيرة:

# In the http {} block: define a shared memory zone keyed by client IP
limit_req_zone $binary_remote_addr zone=crawl_limit:10m rate=10r/s;

server {
    location / {
        limit_req zone=crawl_limit burst=20 nodelay;

        # Return 429 (not the default 503) when the limit is exceeded
        limit_req_status 429;
    }

    # Attach a Retry-After header to 429 responses
    error_page 429 = @too_many;
    location @too_many {
        add_header Retry-After 3600 always;
        return 429;
    }
}

Apache — تحديد المعدل باستخدام mod_ratelimit / mod_evasive

يحدد Apache mod_ratelimit الأساسي عرض النطاق لا عدد الطلبات، لذلك تستخدم عادةً mod_evasive (أو WAF) لتحديد معدل الطلبات. ولجعل الاستجابة المحدودة تعيد 429 مع Retry-After، اضبطها صراحةً:

# Send a 429 with Retry-After for a chosen condition (e.g. a rate-limit env var)
<If "%{ENV:RATE_LIMITED} == '1'">
    Header always set Retry-After "3600"
    Redirect 429 /
</If>

# mod_evasive: throttle abusive request bursts (returns 429 in recent versions;
# older builds default to 403 — override where possible)
<IfModule mod_evasive20.c>
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSBlockingPeriod   60
</IfModule>

انتبه إلى التحفظ: تضبط الإصدارات الأقدم من mod_evasive استجابة الحظر افتراضياً إلى 403 — وهو الرمز الذي تقول Google تحديداً إنه لا ينبغي استخدامه لتحديد معدل الزحف. أكد أن إصدارك يعيد 429 (أو ضع أمامه CDN/WAF يفعل ذلك).

Cloudflare / CDN — تحديد المعدل إلى 429

على طبقة CDN، اجعل استجابة إجراء قاعدة تحديد المعدل 429 (كثير من الإعدادات الافتراضية تكون 403 أو تحدياً). وفي قواعد Rate Limiting في Cloudflare تكون حالة الاستجابة عند تجاوز الحد قابلة للتهيئة — اختر 429 وأرفق Retry-After حيثما كان مدعوماً. والمبدأ نفسه في Fastly وAkamai أو بوابة API: يجب أن يكون الإجراء عند تجاوز الحد 429 Too Many Requests لا 403 Forbidden.

من جهة العميل: إعادة المحاولة بعد 429 من دون صيغة

إذا كنت تكتب العميل، فـRFC يعطيك قاعدة صلبة واحدة ولا يعطيك خوارزمية احتياطية: احترم Retry-After الصالحة عند وجودها. وعند غيابها، لا يحدد RFC 6585 فترة إعادة المحاولة أو صيغة التراجع أو توزيع jitter أو عدد المحاولات أو شرط «النجاح» — فهذه سياستك وليست متطلباً في المواصفة. لا تقدم صيغة واحدة (بما فيها التالية) كأنها قانون HTTP؛ إنها قيمة افتراضية معقولة ومحدودة، لا الخيار الصحيح الوحيد.

on 429 response:
    if Retry-After header present and valid:
        wait = parse(Retry-After)          # seconds or HTTP-date
    else:
        wait = min(cap, base * 2^attempt) + random_jitter(0, jitter_window)

    if attempt >= max_attempts or wait > cap:
        stop and surface the failure        # don't retry forever
    if request is not idempotent (e.g. a POST that isn't safe to repeat):
        confirm idempotency (idempotency key, or a safe no-op check) before retrying
    sleep(wait)
    attempt += 1
    retry request

العناصر المهمة مهما كانت الأرقام التي تختارها: حد أقصى لإجمالي الانتظار وعدد المحاولات (لا تعِد إلى الأبد)، وjitter (حتى لا تعيد مجموعة من العملاء المحاولة في اللحظة نفسها وتعيد تشغيل الحد)، وفحص idempotency قبل إعادة أي طلب غير آمن للتكرار (فـPOST غير idempotent يحتاج مفتاح إزالة تكرار، لا إعادة عمياء).

تحقق من أن الروبوت هو Googlebot فعلاً قبل استثنائه

إذا كنت تكتب استثناءات تحديد المعدل لمحركات البحث، فأكد الهوية بفحص DNS عكسي + أمامي — فسلاسل user-agent المنتحلة باسم «Googlebot» شائعة، وسلسلة UA وحدها لا تثبت شيئاً.

أوامر macOS/Linux محفوظة كما هي داخل كتلة الشيفرة: macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

أوامر Windows محفوظة كما هي داخل كتلة الشيفرة: Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

إذا لم ينته البحث العكسي بنطاق Google، أو لم يطابق البحث الأمامي عنوان IP الأصلي، فليس هذا Googlebot. يمكنك أيضاً مقارنته بنطاقات IP المنشورة لدى Google عبر googlebot.json.

خرافات شائعة عن 429 وSEO

خرافة: «أي 429 سيضر SEO أو يزيلني من الفهرس». لا. صممت Google 429 كإشارة تحديد معدل آمنة ومتوقعة. و429 القصيرة أو المتقطعة طبيعية وتصحح نفسها. لا يظهر خطر إزالة الفهرسة إلا مع 429 المستمرة على العناوين نفسها عدة أيام — وإرشاد اليوم أو اليومين من Google هو الحد.

خرافة: «429 و503 متبادلان عملياً في SEO». في خنق معدل الزحف تتعامل Google معهما بتشابه. لكن معناهما مختلف: 503 Service Unavailable إشارة «غير متاح مؤقتاً/صيانة»، بينما يعبّر 429 تحديداً عن حمل زائد في المعدل/الحجم. ويهم استخدام الرمز الدلالي الصحيح لمراقبتك وأدواتك وأي نظام لاحق يقرأ رموز الحالة — حتى إذا تراجع Googlebot أمام كليهما.

خرافة: «يمكن استخدام 403 أو 404 لإبطاء Googlebot مثل 429». ينفي منشور Illyes في فبراير 2023 ذلك مباشرةً — وكان الأمر شائعاً إلى حد أن Google كتبت مقالاً مخصصاً لتطلب من الناس التوقف. لا يؤثر 403/404 بتاتاً في معدل الزحف ويزيلان المحتوى من الفهرس بنشاط. 429 هو رمز 4xx الوحيد الذي يخنق المعدل.

خرافة: «تحديد معدل روبوتات البحث يسبب خفضاً دائماً لميزانية الزحف». الانخفاض مؤقت ويتعافى تلقائياً بعد هدوء حجم الأخطاء. لا تبقى إشارة معلقة على موقعك بعد توقف الأخطاء — تقول وثائق Google إن معدل الزحف “will automatically start increasing again.” (الترجمة العربية) «سيبدأ معدل الزحف تلقائياً في الارتفاع من جديد.».

خرافة: «إذا حصل Googlebot على 429 فسيتخلى عن العنوان إلى الأبد». سيعيد Google المحاولة لاحقاً. القلق هو 429 المستمر عدة أيام لكل عنوان — لا تحديد معدل عابر أو متقطع، يحترمه Googlebot ويعود بعده.

الأسئلة المتكررة

هل يضر خطأ 429 بـSEO؟ ليس بحد ذاته. يبطئ 429 القصير أو المتقطع Googlebot مؤقتاً ويصلح نفسه. لا يظهر الخطر إلا عندما تعيد العناوين نفسها 429 عدة أيام.

كم يمكنني إعادة 429 قبل أن تزيل Google صفحاتي من الفهرس؟ تقول وثائق Google “a couple of hours, or 1–2 days.” (الترجمة العربية) «بضع ساعات أو يوم إلى يومين». وبعد ذلك “the URL may be dropped from Google’s index.” (الترجمة العربية) «قد يُسقط العنوان من فهرس Google». تعامل مع اليوم أو اليومين كسقف حاد لا كهدف.

ما الفرق بين 429 و503 في SEO؟ تخنق Google الزحف على كليهما بطريقة متشابهة. لكن 503 يعني «غير متاح مؤقتاً/صيانة»، بينما يعني 429 تحديداً «ترسل طلبات كثيرة». استخدم الرمز الدلالي الصحيح حتى تقرأه مراقبتك وأدواتك بشكل سليم.

هل ينبغي حظر Googlebot بـ429 إذا أردت أن يزحف أقل بشكل دائم؟ لا — 429 إشارة قصيرة الأجل لا إعداد دائم. للتقليل المستمر، تقول Google أرسل طلباً خاصاً عن معدل الزحف المرتفع. ولإبقاء الروبوتات خارج مساحة بالكامل استخدم robots.txt؛ ولإزالة صفحة من الفهرس استخدم noindex.

هل يحترم Bingbot 429 بالطريقة نفسها التي يحترمها Googlebot؟ يتراجع Bingbot أيضاً أمام إشارات الحمل الزائد مثل 429/500/503. وتقدم Bing كذلك أدوات استباقية لا تقدمها Google — توجيه crawl-delay في robots.txt وشبكة الطلبات في الثانية في Crawl Control داخل Bing Webmaster Tools.

ما ترويسة Retry-After وهل أحتاج إليها؟ تخبر Retry-After العميل كم ينتظر قبل إعادة المحاولة (عدد ثوانٍ أو تاريخ HTTP). ليست مطلوبة بدقة، لكنها ممارسة جيدة وتمنح الزواحف إشارة تراجع محددة.

هل تستأنف Google الزحف الطبيعي بعد أن أتوقف عن إعادة أخطاء 429؟ نعم، تلقائياً. بعد انخفاض حجم الأخطاء «سيبدأ معدل الزحف في الارتفاع تلقائياً». لا حاجة إلى طلب جديد ولا عقوبة دائمة.

هل يمكن لأدوات WAF أو CDN أن تعيد 429 إلى Googlebot بالخطأ؟ بشكل شائع جداً. قد تصنف قواعد جدار الحماية العدوانية وحدود CDN/الاستضافة الافتراضية وأدوات إدارة الروبوتات Googlebot أو Bingbot خطأً. تحقق من هوية الزاحف (DNS عكسي + أمامي) قبل كتابة الاستثناءات، وخفف الحدود التي تلتقط محركات البحث الحقيقية.

هل 429 خطأ من جهة العميل أم الخادم؟ تقنياً هو خطأ 4xx من جهة العميل في مواصفة HTTP. لكن Google تتعامل معه كخطأ خادم لأغراض الزحف — فهو رمز 4xx الوحيد الذي تجمعه مع 5xx.

ماذا يفعل العميل إذا حصل على 429 بلا ترويسة Retry-After؟ لا توجد صيغة مفروضة من HTTP — تترك المواصفة الأمر للسياسة. افتراضي محدود معقول: تراجع أسي مع jitter، وسقف صارم لإجمالي الانتظار وعدد المحاولات حتى لا تعيد إلى الأبد، وفحص idempotency قبل تكرار أي طلب غير آمن مرتين. راجع علامة Scripts لنسخة pseudocode عملية.

ماذا أفعل حيال 429؟

مشكلات 429 الشائعة

يحصل Googlebot على 429 لكن لا يحصل عليه الزوار العاديون

العرض: تعرض تقارير الزحف 429 بينما تعيد فحوص المتصفح 200. السبب المحتمل: إدارة الروبوتات أو قاعدة UA أو تحديد المعدل حسب IP. الإصلاح: اربط أحداث WAF بعناوين IP لزواحف متحقق منها، ثم ضيّق القاعدة المسؤولة أو صححها؛ لا تسمح لسلسلة user-agent وحدها.

ينخفض معدل زحف اسم المضيف كله

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

تستمر استجابات 429 بعد الحادث

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

ترويسة Retry-After غائبة أو غير صالحة

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

موجه: دقق في قاعدة تحديد المعدل

Review this 429 rate-limit configuration for search-crawler safety. Identify its key,
scope, threshold source, Retry-After behavior, hostname-wide SEO impact, and any
user-agent-only exceptions. Separate deliberate short-term overload protection from
permanent crawl control. Return a minimal safe revision, test matrix, monitoring
signals, and rollback conditions. Do not invent provider syntax.

[PASTE CONFIGURATION AND SANITIZED SAMPLE LOGS]

موجه: شخّص أخطاء 429 غير المفسرة

Use these headers, access-log rows, WAF events, and timestamps to determine which
layer generated the 429 and which traffic dimension triggered it. Give competing
hypotheses ranked by evidence, the next exact check for each, and a fix that does not
trust claimed crawler user agents. Do not infer missing logs.

[PASTE EVIDENCE]

أدوات التحقيق في أخطاء 429

• فاحص رموز حالة HTTP بالجملة: اختبر مجموعة عناوين ممثلة وصدّر المسارات التي تعيد 429 حالياً.
• فاحص ترويسات HTTP: افحص Retry-After وبصمات CDN وقفزات إعادة التوجيه في الاستجابة المحدودة.
• مدقق Googlebot: تحقق من دليل IP قبل إنشاء استثناء للزاحف.
• محلل ملفات السجل: قسّم هدر رموز الحالة حسب الروبوت والقسم مع إبقاء السجلات المرفوعة داخل المتصفح.
• Search Console Crawl Stats: قارن توقيت 429 بتغيرات طلبات الزحف وسلوك استجابة المضيف.

تحقق من إعداد 429

اختبار عقد الاستجابة

الاختبار: شغّل الحد بأمان في بيئة مضبوطة وافحص الاستجابة الخام. النتيجة المتوقعة: 429 مع Retry-After صالحة ومن دون إعادة توجيه عرضية أو رمز نجاح. تفسير الفشل: الطبقة أو قالب الخطأ الخاطئ يملك الاستجابة. نافذة المراقبة: فوراً. مؤشر التراجع: تقييد الطلبات العادية أو زعزعة الاختبار للخدمة.

اختبار النطاق

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

اختبار التعافي

الاختبار: أوقف السبب، وانتظر فترة إعادة المحاولة المضبوطة، ثم أعد الطلبات. النتيجة المتوقعة: عودة استجابات عادية مستقرة من دون معالجة يدوية لكل عنوان. تفسير الفشل: استمرار الأخطاء 429 المخزنة أو حالة محدد المعدل. نافذة المراقبة: الفترة المضبوطة مع انتشار النشر. مؤشر التراجع: بقاء اسم المضيف محدوداً بعد زوال الحمل الأساسي.

اختبار تخزين الذاكرة المؤقتة

الاختبار: ضع ذاكرة مؤقتة أو حافة CDN أمام المسار المحدود، وشغّل 429، ثم اطلب العنوان نفسه بعد زوال الحالة الأساسية. النتيجة المتوقعة: تقييم الطلب الثاني من جديد — بلا 429 مخزنة أو معاد تشغيلها من الحافة. تفسير الفشل: وسيط يخزن استجابة يقول RFC 6585 إنه لا يجوز تخزينها؛ افحص ترويسات cache-control وإعداد قاعدة الحافة، لا الأصل. نافذة المراقبة: فوراً عبر مجموعة ممثلة من عقد/نقاط حافة. مؤشر التراجع: تقديم أي 429 مخزنة بعد تعافي الأصل.

اختبار سياسة إعادة المحاولة للعميل

الاختبار: مرر عميلاً عبر 429 مع وجود ترويسة Retry-After صالحة ومن دونها. النتيجة المتوقعة: ينتظر العميل الفترة المحددة مع الترويسة؛ ومن دونها يطبق تراجعاً محدوداً مع jitter، ويحترم الحد الأقصى للمحاولات، ويفحص idempotency قبل تكرار طلب غير idempotent. تفسير الفشل: عميل يعيد المحاولة فوراً أو بلا حد أو يكرر طلباً غير idempotent عمياناً لديه سياسة إعادة محاولة معطوبة، لا مشكلة امتثال HTTP. نافذة المراقبة: خلال سلسلة إعادة المحاولة المحدودة كاملة. مؤشر التراجع: إعادة العميل تشغيل الحد نفسه بسبب محاولات فورية أو غير محدودة.

مصادر تستحق وقتك

كتاباتي ذات الصلة

• رموز الحالة HTTP وتأثيرها في SEO — دليلي الكامل عن أثر رموز الحالة في SEO، بما فيها موقع 429.
• دليل المبتدئين إلى SEO التقني — موضع ضوابط الزحف ورموز الحالة في الصورة الأكبر.
• قصة حظر صفحتين عاليتَي الترتيب باستخدام robots.txt — تجربة مباشرة عن ما يحدث فعلياً عند قطع الزحف عن الروبوتات.

حديثي

• كيف يعمل البحث (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، بما في ذلك كيف تشير الخوادم للزواحف إلى الإبطاء. (إخلاء المسؤولية الدائم: “This is my understanding of systems… not going to be 100% complete or accurate.” (الترجمة العربية) «هذا فهمي للأنظمة… ولن يكون كاملاً أو دقيقاً بنسبة 100%.»)

من أنحاء المجال

• لا تستخدم 403 أو 404 لتحديد المعدل (Google — من Search Central، بقلم Gary Illyes) — البيان المرجعي بأن 429 هو الاستثناء.
• خفض معدل زحف Google (Google) — نافذة اليوم أو اليومين، والخنق على مستوى اسم المضيف، والتعافي التلقائي.
• تحذر Google من استخدام 403 أو 404 لتحديد معدل زحف Googlebot (Search Engine Land) — تغطية صحفية لمنشور Illyes.
• تقول Google: توقف عن استخدام 403 أو 404 لخفض معدلات زحف Googlebot (Search Engine Roundtable) — ملخص Barry Schwartz الذي يصف 429 بأنه «الاستثناء الوحيد».
• Google: لا تستخدم استجابات 403/404 لتحديد معدل زحف Googlebot (Search Engine Journal) — تغطية مستقلة ثالثة للإرشاد نفسه.
• MDN — 429 طلبات كثيرة جداً — تعريف HTTP ومرجع Retry-After.
• إرشادات Bingbot — إرشاد Bing الحالي لتوجيه crawl-delay.

اختبر نفسك: 429 Too Many Requests

خمسة أسئلة سريعة عن كيفية عمل 429 وتعامل Google معه. اختر إجابة لكل سؤال، ثم تحقق من إجاباتك.

سجل التغييرات