500 خطأ داخلي في الخادم

الخلاصة — يعني خطأ 500 Internal Server Error أن الخادم تعطل أثناء محاولة بناء الصفحة؛ وليست المشكلة في عنوان URL أو المتصفح أو زاحف البحث. عادةً تعيد Google محاولة طلب 500 المنفرد، ولا توجد قاعدة تقول إنه يسبب خسارة بحد ذاته. يكمن الخطر الموثق عندما تعيد صفحات كثيرة لديك أخطاء 500 لفترة؛ عندها تبطئ Google الزحف، وقد تزيل الصفحات من نتائج البحث في النهاية. ابدأ الإصلاح بفحص سجلات أخطاء الخادم، لا المتصفح.

ما هو خطأ 500

خطأ 500 Internal Server Error هو النسخة الويب من «حدث خطأ ما ولا أستطيع إخبارك بماهية الخطأ تحديداً». تلقى الخادم طلبك، وبدأ بناء الصفحة، ثم واجه مشكلة واستسلم؛ فأعاد خطأً عاماً بدلاً من الصفحة. صغتُه في دليل Ahrefs لرموز حالة HTTP هكذا: الخادم «يواجه نوعاً من المشكلات ولا يملك رمز خطأ أفضل أو أكثر تحديداً». Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

“encounters some kind of issue and doesn’t have a better or more specific error code.” (ترجمة) «يواجه مشكلة ما ولا يملك رمز خطأ أفضل أو أكثر تحديدًا.»

هذا هو الأمر الأساسي الذي ينبغي فهمه: 500 رمز شامل. يخبرك بأن شيئاً ما تعطل من جهة الخادم، لكنه لا يخبرك ما هو. العثور على إجابة «ما الذي تعطل؟» هو المهمة كلها.

إنها مشكلة خادم، وليست مشكلتك (عادةً)

تقع أخطاء 500 ضمن عائلة 5xx — أي أخطاء الخادم. وهذا يختلف عن أخطاء 4xx مثل 404 (الصفحة غير موجودة)، التي تتعلق بالطلب (عنوان URL خاطئ أو مفقود). مع 500 قد يكون عنوان URL سليماً تماماً؛ لكن الخادم لم يستطع إتمام العمل. وسترى أيضاً أشقاء 500: 502 و503 و504، وهي أخطاء من جهة الخادم كذلك، لكنها تشير إلى حالات أكثر تحديداً (بوابة سيئة، أو خادم غير متاح مؤقتاً، أو انتهاء مهلة).

هل يضر خطأ 500 بتحسين محركات البحث؟

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

الخطر الحقيقي الموثق هو أخطاء الخادم المستمرة عبر عدد كبير من الصفحات. عندما يحدث ذلك:

1. تواصل Google إعادة المحاولة، وترى استمرار الأخطاء، ثم تبطئ سرعة زحفها إلى موقعك.
2. إذا لم تختفِ الأخطاء، تزيل Google تلك الصفحات من الفهرس في النهاية — أي تتوقف عن ظهورها في البحث. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

الخبر الجيد هو أن وثائق Google نفسها تصف تعافياً تدريجياً بعد إصلاح المشكلة الأساسية وبدء نجاح عمليات الزحف مجدداً؛ لكنها لا تضمن مدة زمنية أو نتيجة. وعبارة “Recovery is usually quick” (ترجمة) «التعافي عادةً سريع» تصف الحالة الشائعة، وليست وعداً.

كيف تبدأ إصلاحه

• افحص سجلات أخطاء الخادم أولاً. هناك يوجد السبب الحقيقي — لا في المتصفح. يعرض المتصفح «500» فقط، أما السجلات فتوضح لماذا.
• انظر إلى ما تغير مؤخراً. إضافة أو سمة أو وحدة جديدة؟ عملية نشر حديثة؟ تعديل في ملف إعداد مثل .htaccess؟ التغييرات الحديثة هي المشتبهون المعتادون.
• افحص Google Search Console. يحتوي تقرير فهرسة الصفحات على قسم «خطأ الخادم (5xx)» الذي يوضح عناوين URL التي ترى Google أنها تعيد 500.
• اسأل مضيفك. خصوصاً في الاستضافة المشتركة، تنتج أخطاء 500 كثيرة عن بلوغ حدود الذاكرة أو الموارد؛ وغالباً يستطيع المضيف رؤيتها من جهته.

هل تريد النسخة الأعمق — كيف تصعّد Google الاستجابة بدقة، وقاعدة ~1% التقريبية، والفرق بين 500 و503، وترتيب تشخيص كامل؟ انتقل إلى علامة التبويب Advanced.

الخلاصة — يعرّف RFC 9110 الرمز 500 بأنه حالة غير متوقعة منعت الخادم من تنفيذ الطلب؛ وهذا هو كامل الحد الدلالي لرمز الحالة نفسه، أما السبب والمدة وصلاحية إعادة المحاولة فهي موضوع تشخيص لا دلالة بروتوكولية. استجابة Google الموثقة تدريجية: تعاد محاولة أخطاء 500 المنفردة عادةً؛ أما أخطاء 500 المستمرة على مستوى الموقع فتؤدي إلى زحف أبطأ، ثم إلى إزالة من الفهرس إذا لم تُحل. عرض Mueller قاعدة تقريبية وشخصية — أن معدل الأخطاء الأعلى من نحو 1% يعني على الأرجح أن شيئاً ما معطل — لكنها ليست عتبة موثقة من Google، كما أن تسلسل إعادة المحاولة ثم إبطاء الزحف ثم الإسقاط يصف سلوكيات موثقة لا مؤقتاً ثابتاً متتابعاً. شخّص من سجلات الخادم أولاً، ثم من تقرير «خطأ الخادم (5xx)» في GSC ومن إحصاءات الزحف «حسب الاستجابة». الفرق بين 500 و503 مهم: 503 هو رمز «عد لاحقاً» المصرح به مع مهلة سماح تقارب يومين؛ أما 500 غير المنضبط فلا يملك هذه المهلة. Evidence for this claim RFC 9110 defines 500 as an unexpected condition encountered by the server that prevented it from fulfilling the request. Scope: web requests Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

ما هو 500 فعلياً

ابدأ بالمواصفة، لا بالاختصار العملي. يعرّف RFC 9110 — معيار دلالات HTTP — خطأ 500 Internal Server Error بأنه حالة غير متوقعة منعت الخادم من تنفيذ الطلب. هذا هو كل ما يخبرك به رمز الحالة نفسه. فهو لا يحدد السبب الجذري، أو المكوّن المتعطل، أو مدة المشكلة، أو ما إذا كان الطلب نفسه سينجح عند إعادة المحاولة، أو ما إذا كان التعافي مرجحاً. كل ما يتجاوز «واجه الخادم شيئاً لم يستطع التعامل معه» هو تشخيص لا دلالة رمز الحالة؛ والتشخيص موجود في سجلات أخطاء الخادم، لا في المواصفة أو المتصفح. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

أحافظ في دليل Ahrefs لرموز حالة HTTP على تعريف عملي مباشر عمداً: الخادم «يواجه نوعاً من المشكلات ولا يملك رمز خطأ أفضل أو أكثر تحديداً». هذه صياغة مبسطة لحد RFC نفسه؛ فهو رمز شامل، وعَرَض لا تشخيص.

يقع 500 ضمن عائلة 5xx إلى جانب 502 (بوابة سيئة)، و503 (الخدمة غير متاحة)، و504 (انتهاء مهلة البوابة) — وكلها من جهة الخادم، لكن 500 هو الرمز الذي يعني «لا ينطبق رمز أفضل». وبما أن رمز الحالة نفسه لا يحمل تفاصيل التشخيص، فلن يخبرك تحديث المتصفح بسبب حدوثه؛ سجلات أخطاء الخادم هي مصدر الحقيقة.

كيف يتعامل Googlebot مع 500

زاحف Google مصمم ليكون مهذباً؛ فهو يضبط سرعته وفق صحة الخادم، وتعد استجابات 5xx إحدى الإشارات التي يقرأها بمعنى «أبطئ». وتؤكد وثائق Google الحالية شكل هذه الاستجابة: تؤدي استجابات 5xx و429 إلى خفض مؤقت لمعدل الزحف (يتناسب مع عدد عناوين URL المتأثرة)، ويمكن إزالة عناوين URL التي تستمر في الفشل من الفهرس في النهاية، بينما يُحافَظ مؤقتاً على المحتوى المفهرس إلى أن تنجح عملية تحديث. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers وقد وصف John Mueller التسلسل نفسه بكلماته في جلسة Google SEO Office Hours نقلتها Search Engine Journal:

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (ترجمة) «لا توجد عتبات قوية؛ تعيد Google محاولة أخطاء 500، ثم تبطئ الزحف، ثم تزيل العناوين من الفهرس إذا استمرت الأخطاء.»

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

لماذا تكون أخطاء الخادم على مستوى الموقع أسوأ من الأخطاء المنفردة

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

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (ترجمة) «إذا كانت نسبة كبيرة من الموقع تعيد أخطاء 500 باستمرار، فقد تفترض Google أن زحفها يسبب المشكلة، فتبطئ زحف الموقع كله، ثم تسقط الصفحات إذا بدا أنها زالت.»

تعامل مع صياغة «نفترض أننا نسبب المشكلة» بوصفها توصيف Mueller الشخصي، لا نصاً منقولاً حرفياً من وثائق Google الحالية؛ فالآلية الأساسية موثقة (كلما زادت عناوين URL الفاشلة زاد خفض معدل الزحف)، حتى لو كان التفسير السببي الدقيق أسهل تحققاً من تصريحه هو. وفي كل الأحوال، تستحق حلقة التغذية الراجعة العملية أن تترسخ: قد يؤدي الزحف المكثف أثناء استنفاد الموارد إلى مزيد من أخطاء 500 → تتراجع Google عن زحف الموقع كله → وإذا استمرت الأخطاء تهبط الصفحات. وهذا يعني أيضاً أن مشكلة 500 ليست دائماً خللاً في الشيفرة؛ فقد يكون الخادم ينهار أحياناً تحت حمل متزامن لا يظهر إلا أثناء ارتفاعات الزحف أو حركة المرور.

ما مقدار الخطأ «الكبير جداً»؟

لا توجد حدود صلبة؛ فوثائق استكشاف أخطاء Google نفسها لا تنشر عتبة لمعدل الأخطاء. وقد قدم Mueller قاعدة تقريبية شخصية في SEO Office Hours (نقلتها Search Engine Journal مرة أخرى، لا منشور رسمي من Google):

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (ترجمة) «أشعر بأن رؤية معدل يتجاوز واحدًا بالمئة تعني على الأرجح أن شيئًا ما معطل.»

تعامل مع ~1% بوصفها اختبار رائحة غير رسمي منسوباً إلى Mueller، لا حداً موثقاً أو مفروضاً من Google. غالباً لا مشكلة تحتها؛ وفوقها يستحق الأمر التحقيق، لكن لا تتعامل مع تجاوز 1% كمشغل تلقائي، ولا مع البقاء تحتها كضمان. الرقم الوحيد الذي تلتزم به Google علناً هو غياب الرقم: «لا توجد لدينا عتبات قوية».

500 مقابل 503: الفرق المهم

هنا يخطئ كثير من الناس. 503 Service Unavailable هو الطريقة المصرح بها لإخبار الزاحف «أنا متوقف مؤقتاً، عد لاحقاً». تتعامل Google معه بوصفه مقصوداً وتمنحه مهلة سماح. وتوضح وثيقة استكشاف أخطاء الزحف لدى Google ذلك صراحةً:

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (ترجمة) «أعد رمزي استجابة HTTP 503 أو 429 مؤقتًا لطلبات Googlebot عند زيادة حمل الخادم؛ وستعيد Google المحاولة نحو يومين، لكن استمرار رموز عدم التوفر أكثر من بضعة أيام يبطئ الزحف أو يوقفه نهائيًا.»

الخلاصة: 503 مقصود ويحصل على مهلة إعادة محاولة تقارب يومين؛ أما 500 غير المنضبط فغير مقصود ولا يحصل على هذه المهلة — بل يعاد طلبه فقط إلى أن تستسلم Google. عملياً: في الصيانة المخطط لها أو الدفاع المقصود ضد حمل زائد، أعد 503 (ويفضل مع ترويسة Retry-After) لا 500 ولا صفحة خطأ برمز 200. لا تكسُ انقطاعاً حقيقياً برد 200.

كيف تشخّص خطأ 500

اعمل عبر هذه الطبقات — التطبيق/الشيفرة، ثم المنصة أو CMS، ثم البنية التحتية والموارد، ثم الإعداد — وابدأ بالأرخص والأكثر احتمالاً لإعطاء نتيجة. الخطوات الموسومة (خاصة بـWordPress) ممارسة شائعة في WordPress وليست إصلاحات عامة؛ عدّلها وفق المكدس الفعلي لديك.

1. سجلات أخطاء الخادم. افحص error.log / access.log (أو عارض سجلات منصتك). طابق التوقيت مع الطلبات الفاشلة. هنا يظهر تتبع الاستدعاءات الحقيقي، أو خطأ PHP القاتل، أو فشل اتصال قاعدة البيانات. وكل ما يأتي بعد ذلك تخمين حتى تقرأ هذه السجلات.
2. GSC — تقرير خطأ الخادم (5xx). يحدد تقرير فهرسة الصفحات في Google Search Console عناوين URL التي ترى Google نفسها أنها تعيد 500. ثم افتح إحصاءات الزحف واقرأ تفصيل «حسب الاستجابة» عبر الزمن؛ هكذا تميز العارض المؤقت من مشكلة التوفر الحقيقية والمستمرة.
3. Bing Webmaster Tools. تجمع تنبيهات أخطاء الزحف لديها أخطاء الخادم (5xx) وتوجهك إلى عناوين URL المحددة وأداة معلومات الزحف.
4. أعد إنتاج المشكلة كروبوت، لا كمتصفح فقط. قد تعيد الصفحة 500 لـGooglebot بينما تعمل لديك؛ بسبب حمل سببه الزحف، أو إعداد خاطئ لاكتشاف الروبوت/جدار الحماية، أو حدود لا تظهر إلا مع حركة روبوتات متزامنة. استخدم فحص عنوان URL (GSC)، أو Fetch as Bingbot، أو curl مع user-agent لروبوت كي تلتقط الأعطال الخاصة بالروبوت. عبارة «يعمل في متصفحي» ليست تصريح سلامة.
5. تعارض الإضافات / السمات / الوحدات (نمط خاص بـWordPress؛ عدّله لغيره). خذ نسخة احتياطية أولاً؛ يجب أن تملك دائماً طريقاً للعودة قبل تعطيل الأشياء. ثم عطّل الإضافات وأعد تفعيلها واحدة تلو الأخرى لعزل المتسبب، مع فحص أذونات/ملكية الملفات التي تلمسها. توثق أدلة استكشاف أخطاء WordPress لدى شركات الاستضافة هذا النمط كثيراً، لكنه ملاحظة خاصة بمكدس معين لا دليل على أنه السبب الأول في كل مكان؛ وفي CMS مختلف أو تطبيق مخصص يكون المقابل تعارض وحدة أو حزمة أو وسيط تابع لجهة خارجية.
6. استنفاد الموارد. حدود ذاكرة PHP، وحدود اتصالات قاعدة البيانات، وسعة الاستضافة المشتركة، وارتفاعات حركة المرور أو الزحف. يستطيع المضيف غالباً تأكيد ذلك من جهته.
7. الإعداد والتغييرات الحديثة. ملف .htaccess مكسور، أو تعديل سيئ في إعداد الخادم، أو عملية نشر حديثة، أو بيانات اعتماد قاعدة بيانات خاطئة. التغييرات الحديثة أعلى الأماكن مردوداً للفحص.

كيف تصلحه (طابق الإصلاح مع السبب)

طابق الإصلاح مع الطبقة التي أشار إليها التشخيص. هذه أنماط شائعة وردت في كتابات الممارسين، وليست قائمة مرتبة أو شاملة لما هو الأرجح في مكدسك المحدد:

• تسبب الإعداد/النشر في المشكلة → أعد التغيير، وأصلح .htaccess أو الإعداد أو بيانات الاعتماد.
• استنفاد الموارد → ارفع الحدود (ذاكرة PHP واتصالات قاعدة البيانات) أو رقِّ فئة الاستضافة؛ وإذا كان الزحف يطلق الحمل الزائد فهذه أيضاً مسألة معدل زحف.
• تعارض إضافة/وحدة → أزل الإضافة المتسببة أو استبدلها.
• خلل في الشيفرة → أصلح الشيفرة وأضف معالجة الخطأ المفقودة.
• لا تستطيع معرفة السبب → صعّد الأمر إلى مضيفك مع التوقيتات الدقيقة وأسطر السجل. لا تخمّن في الإنتاج.

منع تكراره

مراقبة معدلات 5xx والتنبيه عليها، وتجهيز التغييرات في بيئة مرحلية قبل وصولها إلى الإنتاج، واختبار الحمل قبل ارتفاعات المرور المعروفة، وإذا كان زحف Googlebot نفسه هو المحفز — إدارة حمل الزحف (وإعادة 503/429 عمداً أثناء الحمل الزائد الحقيقي، بدلاً من ترك الخادم يصدر أخطاء الخادم غير منضبطة).

الأسئلة الشائعة

هل يضر خطأ 500 بتحسين محركات البحث؟ الخطر الموثق يتعلق أساساً بالاستمرار وعلى نطاق واسع. عادةً تعاد محاولة أخطاء 500 المنفردة، ولا توجد عقوبة موثقة لعارض واحد؛ أما أخطاء 500 المستمرة على مستوى الموقع فتبطيء الزحف وقد تؤدي إلى إزالة الفهرسة.

كم من الوقت قبل أن تزيل Google صفحة بها 500 من الفهرس؟ لا توجد مدة ثابتة. تعيد Google المحاولة أولاً وتبطئ الزحف؛ ولا يحدث الإسقاط من الفهرس إلا إذا استمرت الأخطاء. أصلح المشكلة، وعموماً تعود الصفحات بعد نجاح الزحف مجدداً.

لماذا يعيد موقعي 500 لـGooglebot بينما يعمل جيداً في متصفحي؟ تعني أخطاء 500 الخاصة بالروبوت عادةً مشكلات في السعة أو معالجة الروبوت — حمل يسببه الزحف، أو قواعد جدار حماية/روبوت، أو حدود لا تظهر إلا مع حركة روبوتات متزامنة. ثق بالسجلات، لا بفحص متصفح يدوي.

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

ما الذي يسبب 500 في WordPress؟ في WordPress تحديداً، تذكر شركات الاستضافة ومجتمع WordPress غالباً تعارض الإضافات/السمات، أو ملف .htaccess تالفاً، أو بلوغ حد ذاكرة PHP؛ وهذا ما تذكره تلك المنصة، وليس ادعاءً بأنها الأسباب الأولى الشاملة لكل خطأ 500. ترتيب التشخيص أعلاه (السجلات أولاً ثم ما تغير) نفسه مهما كان CMS.

هل من الآمن إعادة محاولة الطلب تلقائياً بعد 500؟ فقط بعد فحص الطريقة وكون الطلب idempotent أولاً؛ فرمز 500 نفسه لا يمنح سياسة إعادة المحاولة. تكون GET وHEAD وPUT وDELETE آمنة عموماً لإعادة المحاولة لأنها idempotent (تكرارها لا ينبغي أن يسبب آثاراً جانبية إضافية)؛ أما POST المجرد فعادةً ليس كذلك، إلا إذا ضمن API صراحةً idempotency (مثلاً عبر مفتاح idempotency)، وإلا فإن إعادة محاولته عشوائياً قد تكرر طلباً أو بريداً إلكترونياً أو خصماً مالياً. عند إعادة المحاولة استخدم exponential backoff مع jitter، وحدد عدد المحاولات، وضع ميزانية لإعادة المحاولة حتى لا يضرب خادم متعثر بعاصفة محاولات فوق كل ما يفشل أصلاً.

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

خلاصة مركزة من النسخة المتقدمة:

• 500 = حد الحالة غير المتوقعة في RFC 9110. هذا هو نطاق رمز الحالة نفسه بالكامل؛ لا سبب جذري ولا مدة ولا صلاحية لإعادة المحاولة. إنه عَرَض لا تشخيص؛ ابحث عن السبب الجذري في سجلات الخادم لا المتصفح. وهو مميز عن أخطاء 4xx (العميل/الطلب) وعن أشقائه 5xx: 502 و503 و504.
• استجابة Google موثقة ومتدرجة: خفض مؤقت لمعدل الزحف (يتناسب مع عدد عناوين URL المتأثرة)، ثم احتمال إزالة عناوين URL التي تستمر في الفشل من الفهرس، مع التعافي بعد نجاح عمليات الجلب. يصف Mueller ذلك بإعادة المحاولة → إبطاء الزحف → الإسقاط من الفهرس؛ وهذا وصف لسلوكيات موثقة لا مؤقت ثابت متتابع. يعاد عادةً طلب 500 المنفرد؛ ولا يوجد وعد بأنه بلا تكلفة، لكن الخطر الموثق الحقيقي هو الاستمرار على نطاق واسع.
• أخطاء 500 على مستوى الموقع أسوأ: يتناسب خفض معدل الزحف مع عدد العناوين الفاشلة. ويصوغ Mueller السبب على أنه احتمال أن يكون زحف Google نفسه جزءاً من الحمل الزائد؛ وهذا توصيفه لا نصاً حرفياً من الوثائق، وفي كلتا الحالتين تنشأ حلقة قد يسبب فيها حمل الزحف مزيداً من أخطاء 500.
• قاعدة تقريبية لا عتبة: قال Mueller إن معدلات الأخطاء فوق ~1% «غالباً معطلة»، لكن ذلك تأطيره الشخصي من SEO Office Hours، لا حداً موثقاً من Google؛ فGoogle تقول إنه لا توجد عتبات صلبة.
• 500 مقابل 503: 503 (أو 429) إشارة «عد لاحقاً» مصرح بها مع مهلة إعادة محاولة تقارب يومين وفق وثائق Google؛ أما 500 غير المنضبط فلا مهلة له. استخدم 503 (مع Retry-After) للتوقف المخطط.
• ترتيب التشخيص حسب الطبقة: سجلات الخادم → خطأ الخادم في GSC (5xx) + إحصاءات الزحف «حسب الاستجابة» → Bing Webmaster Tools → إعادة الإنتاج كروبوت (فحص عنوان URL / curl) → تعارض الإضافات/الوحدات (نمط خاص بـWordPress؛ عدّله لغيره، وخذ نسخة احتياطية أولاً) → استنفاد الموارد → تغييرات الإعداد/النشر.
• سلامة إعادة المحاولة تعتمد على الطلب لا رمز الحالة. الطرق idempotent (GET/HEAD/PUT/DELETE) آمنة عموماً لإعادة المحاولة؛ أما POST المجرد فعادةً ليس آمناً من دون مفتاح idempotency. استخدم backoff، وحداً للمحاولات، وميزانية إعادة محاولة.
• التعافي سريع عموماً بعد الإصلاح؛ تميل الصفحات المسقطة إلى العودة مع نجاح الزحف، لكن Google لا تضمن مدة أو نتيجة.

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

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

Google

• استكشاف أخطاء زحف Google Search وإصلاحها — كيف تتعامل Google مع أخطاء الخادم، وكيفية استخدام 503/429 المصرح بهما أثناء الحمل الزائد المؤقت.
• دليل متعمق لكيفية عمل Google Search — مجدول الزحف وكون استجابات 5xx تُقرأ بمعنى «أبطئ».
• تقرير إحصاءات الزحف — تفصيل «حسب الاستجابة» (ومن ضمنه خطأ الخادم (5xx)) لتمييز العارض من المشكلة المستمرة.
• تقليل معدل زحف Googlebot — الطريقة الصحيحة والمقصودة لإبطاء الزحف، بدلاً من ترك الخادم يصدر أخطاء الخادم غير منضبطة.

Microsoft — محرك Bing

• أدوات مشرفي مواقع Bing — قائمة تنبيهات أخطاء الزحف — كيف تجمع Bing أخطاء الخادم (5xx) وأين تفحص عناوين URL المتأثرة.

مواصفة HTTP / مرجع

• MDN — 500 خطأ داخلي في الخادم — تعريف رمز الحالة نفسه.
• RFC 9110 §15.6.1 — 500 خطأ داخلي في الخادم — دلالات HTTP المرجعية المعتمدة.

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

تصريحات مسجلة. إذا كانت صفحة المصدر تعمل عبر JavaScript أو نُقلت عبر تغطية ثانوية، فسيظهر ذلك في ملاحظة <small>.

Google — مسار التصعيد

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (ترجمة) «لا توجد عتبات قوية؛ تعيد Google محاولة أخطاء 500، ثم تبطئ الزحف، ثم تزيل العناوين من الفهرس إذا استمرت الأخطاء.» — John Mueller، Google. اقرأ التغطية منقول عبر نص Search Engine Journal لفيديو Google SEO Office Hours؛ أكد الصياغة مقابل الفيديو الأصلي قبل اعتبارها نهائية.
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (ترجمة) «إذا كانت نسبة كبيرة من الموقع تعيد أخطاء 500 باستمرار، فقد تفترض Google أن زحفها يسبب المشكلة، فتبطئ زحف الموقع كله، ثم تسقط الصفحات إذا بدا أنها زالت.» — John Mueller، Google. اقرأ التغطية منقول عبر Search Engine Journal؛ تحقق من الحرفية مقابل الفيديو الأصلي.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (ترجمة) «أشعر بأن رؤية معدل يتجاوز واحدًا بالمئة تعني على الأرجح أن شيئًا ما معطل.» — John Mueller، Google، عن قاعدة تقريبية لمعدل الأخطاء. اقرأ التغطية منقول عبر Search Engine Journal؛ تحقق من الحرفية مقابل الفيديو الأصلي.

Google — إشارة «أبطئ» المصرح بها (وثائق موثقة)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (ترجمة) «أعد 503 أو 429 مؤقتًا لطلبات Googlebot عند زيادة حمل الخادم؛ وستعيد Google المحاولة نحو يومين، لكن استمرار رموز عدم التوفر أكثر من بضعة أيام يبطئ الزحف أو يوقفه نهائيًا.» — وثائق Google Search Central. انتقل إلى الاقتباس

Patrick Stox — التعريف (Ahrefs، موثق)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (ترجمة) «خطأ 500 يعني أن الخادم واجه مشكلة ولم يملك رمز خطأ أفضل أو أكثر تحديدًا.» — دليلي عن رموز الحالة HTTP في مدونة Ahrefs. انتقل إلى الاقتباس

قائمة فرز أخطاء 500

نفّذها من الأعلى إلى الأسفل فور ظهور أخطاء الخادم:

• سحبت سجلات أخطاء الخادم ووجدت الخطأ الحقيقي (تتبع الاستدعاء / خطأ PHP القاتل / فشل قاعدة البيانات) — لا مجرد «500» في المتصفح.
• تحققت من ما تغير مؤخراً — إضافة/سمة/وحدة جديدة، أو نشر حديث، أو تعديل .htaccess أو إعداد الخادم، أو تغيير بيانات اعتماد قاعدة البيانات.
• فتحت GSC → فهرسة الصفحات → خطأ الخادم (5xx) لمعرفة عناوين URL التي ترى Google أنها تعيد 500.
• قرأت إحصاءات زحف GSC «حسب الاستجابة» عبر الزمن للحكم على كون المشكلة عارضة أو مستمرة.
• تحققت من تنبيهات أخطاء الزحف في Bing Webmaster Tools للعناوين نفسها.
• أعدت الإنتاج كروبوت (فحص عنوان URL / Fetch as Bingbot / curl مع user-agent لـروبوت) — لا في متصفح فقط.
• استبعدت استنفاد الموارد (ذاكرة PHP، اتصالات قاعدة البيانات، سعة الاستضافة) مع المضيف.
• عزلت أي تعارض إضافة/وحدة بتعطيلها وإعادة تفعيلها واحدة تلو الأخرى.
• أكدت أنك لا تصدر أخطاء 500 غير منضبطة أثناء التوقف المخطط — استخدم 503 (مع Retry-After) بدلاً من ذلك.
• تحققت بعد الإصلاح من عودة معدل الأخطاء تحت اختبار الرائحة غير الرسمي ~1% (قاعدة Mueller التقريبية، وليست عتبة موثقة من Google)، ومن أن GSC يعرض عمليات زحف ناجحة مجدداً.

دليل تشغيل: «الموقع يصدر أخطاء الخادم — ما أول ما أفحصه؟»

ترتيب عمليات بلا هلع. نفذ الخطوات بالتتابع، وتوقف عندما تجد السبب وتصلحه.

0. حدد النطاق (دقيقتان). هل هو عنوان URL واحد، أم قالب/قسم واحد، أم الموقع كله؟ عنوان واحد منخفض المخاطر (تعيد Google المحاولة). أما مستوى الموقع فهو الطارئ — فهذا هو النمط الذي يجعل Google تبطئ زحف الموقع.

1. اقرأ سجلات أخطاء الخادم. ابدأ بـerror.log. طابق التوقيت مع حالات الفشل. ابحث عن السبب الحقيقي: خطأ PHP قاتل، أو فشل اتصال قاعدة البيانات، أو إنهاء بسبب segfault، أو إيقاف بسبب نفاد الذاكرة. كل ما يأتي أدناه تخمين حتى تفعل ذلك.

2. اربط المشكلة بـ«ما الذي تغير». رتّب التغييرات الحديثة: آخر عملية نشر، إضافة/سمة/وحدة أضيفت أو حُدثت، تعديل .htaccess، تدوير بيانات اعتماد قاعدة البيانات، أو دفع إعداد جديد. تتبع معظم أخطاء الخادم إلى تغيير في الساعات أو الأيام الأخيرة. وإن أمكن، أعده أولاً ثم شخّص ثانياً؛ فاستعادة الخدمة تمنحك وقتاً.

3. تأكد من منظور محرك البحث. افتح GSC → فهرسة الصفحات → خطأ الخادم (5xx) للعناوين المتأثرة، ثم إحصاءات الزحف → حسب الاستجابة لمعرفة هل هو عارض أم مستمر. وقارن بتنبيهات أخطاء الزحف في Bing Webmaster Tools. فهذا يوضح مدى إلحاح ساعة SEO.

4. أعد إنتاج المشكلة كما يراها الروبوت. إذا حصل البشر على الصفحة بشكل سليم بينما يحصل Googlebot على أخطاء الخادم، فاختبر كروبوت: فحص عنوان URL، أو Fetch as Bingbot، أو curl -A "Googlebot" <url>. وتشير أخطاء الخادم الخاصة بالروبوت إلى السعة، أو قواعد جدار الحماية/الروبوت، أو الحمل الذي يسببه الزحف؛ وهذا إصلاح مختلف عن خلل الشيفرة.

5. قسّم المشتبهين المعتادين.

• الإضافات/الوحدات: عطّلها كلها، ثم أعد تفعيلها واحدة تلو الأخرى حتى يعود العطل.
• الموارد: افحص حد ذاكرة PHP، وسقف اتصالات قاعدة البيانات، وسعة الاستضافة مع المضيف، خصوصاً إذا تكتلت أخطاء الخادم حول ارتفاعات المرور أو الزحف.
• الإعداد: أعد .htaccess / إعداد الخادم إلى نسخة معروفة السلامة.

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

7. تحقق من التعافي. عاد معدل الأخطاء تحت اختبار الرائحة غير الرسمي ~1%، وأصبحت السجلات نظيفة، وأظهرت إحصاءات زحف GSC عمليات جلب ناجحة مجدداً. تعود الصفحات المسقطة عموماً مع نجاح الزحف؛ لا توجد مدة مضمونة، لكن التعافي سريع عادةً.

نمط التصعيد الذي ينبغي تذكره: 500 عارض → يعاد طلبه عادةً، وخطره الموثق منخفض → 500 مستمر → يتباطأ الزحف → استمرار الفشل → تسقط عناوين URL من الفهرس. لا تنشر Google توقيتاً دقيقاً لهذه الانتقالات؛ مهمتك قطع السلسلة قبل أن تصل إلى ذلك.

أي رمز خادم ينبغي أن أعيد؟

استخدم هذا عندما تقرر ما الذي ستقدمه أو تفسر ما تراه.

هل الفشل مقصود (صيانة / دفاع متعمد ضد الحمل الزائد)؟

• نعم → أعد 503 Service Unavailable مع ترويسة Retry-After. تتعامل Google معه مؤقتاً وتعُد لإعادة المحاولة لنحو يومين. لا تقدم صفحة خطأ برمز 200، ولا تدع الأمر يسقط إلى 500.
• لا (إنه فشل حقيقي غير متوقع) → تابع.

هل يحصل الجميع على الخطأ أم الزاحف فقط؟

• الجميع → هذه مشكلة شيفرة / إعداد / قاعدة بيانات. اذهب إلى سجلات أخطاء الخادم وقائمة «ما الذي تغير». أعد التغييرات الحديثة.
• Googlebot/Bingbot فقط → اشتبه في السعة، أو قواعد اكتشاف الروبوت/جدار الحماية، أو حمل سببه الزحف. أعد الإنتاج كروبوت، وافحص موارد الخادم وأي قواعد للروبوت.

هل هو عنوان URL واحد أم نسبة كبيرة من الموقع؟

• عنوان واحد / عارض → إلحاح منخفض. تعيد Google المحاولة؛ أصلحه على مهل لكن تأكد من أنه معزول فعلاً.
• الموقع كله / مستمر → طارئ. هذا هو النمط الذي يجعل Google تبطئ زحف الموقع كله ثم تزيل الفهرسة في النهاية. استعد الخدمة أولاً (أعد التغيير)، ثم ابحث عن السبب الجذري.

هل معدل الأخطاء أعلى من ~1%؟

• نعم → يستحق التحقيق بوصفه مشكلة محتملة حقيقية؛ هذه قاعدة Mueller التقريبية غير الرسمية، وليست عتبة موثقة من Google.
• لا → غالباً لا مشكلة، لكن راقب الاتجاه لا اللقطة المنفردة.

موجه: اربط خطأ 500 بالسجلات وعملية النشر

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

موجه: حوّل تتبع الاستدعاء إلى خطة اختبار آمنة

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: خذ عينة من قائمة عناوين URL لاستجابات 5xx

شغّل هذا مع عنوان URL مطلق واحد في كل سطر من urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

يفصل الناتج بين المسارات المعزولة والفشل الواسع، ويسجل زمن الاستجابة من دون تنزيل أجسام الاستجابة.

PowerShell: صدّر عينة الحالة نفسها

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: احسب حالات 5xx في سجل وصول

عدّل موضع حقل الحالة ليتطابق مع تنسيق السجل الموثق لديك قبل الاعتماد على النتيجة.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

أدوات العثور على أخطاء الخادم وتشخيصها

• سجلات أخطاء الخادم — error.log / access.log، أو عارض سجلات المضيف/المنصة. أهم أداة منفردة؛ فالسبب الحقيقي موجود هنا.
• Google Search Console — فهرسة الصفحات — يسرد قسم «خطأ الخادم (5xx)» عناوين URL التي ترى Google أنها تعيد 500.
• GSC — تقرير إحصاءات الزحف — يفصل «حسب الاستجابة» عبر الزمن بين عارض مؤقت ومشكلة توفر مستمرة.
• GSC — فحص عنوان URL — اجلب عنواناً واحداً كما تراه Google لإعادة إنتاج خطأ 500 خاص بالروبوت.
• Bing Webmaster Tools — تجمع تنبيهات أخطاء الزحف أخطاء الخادم (5xx) وتوجهك إلى أداة معلومات الزحف.
• curl — أعد الإنتاج باستخدام user-agent عشوائي: curl -I -A "Googlebot" <url> لترى رمز الحالة كما يراه الروبوت.
• الزواحف / تدقيقات الموقع — يعرض Ahrefs Site Audit وScreaming Frog SEO Spider استجابات 5xx عبر الموقع ويساعدانك على رؤية الأنماط (قالب أو قسم كامل معطل).
• مراقبة التوفر/الحالة — تنبيه عند ارتفاع معدلات 5xx كي تعرف بالارتفاع قبل Google.

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

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

• رموز حالة HTTP: دليل لتأثيرها في SEO وتجربة المستخدم — مرجعي الكامل لرموز الحالة، بما فيه تعريف 500 وتأطير الزحف الأوسع لأخطاء 5xx.
• دليل المبتدئ إلى SEO التقني — موقع أخطاء الخادم في الصورة التقنية الأكبر.

كلماتي ومحاضراتي

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

من أوساط الصناعة

• كيف يمكن لرموز خطأ 500 أن تؤثر سلباً في الفهرسة (Search Engine Journal) — مقال Matt G. Southern مع اقتباسات John Mueller عن إعادة المحاولة → الزحف البطيء → الإسقاط من الفهرس، وقاعدة ~1%.
• إصلاح خطأ «خطأ الخادم (5xx)» في Google Search Console (من Search Engine Land) — شرح خطوة بخطوة لتقرير GSC.
• كيفية إصلاح «خطأ الخادم (5xx)» في Google Search Console (Onely) — ماهية أخطاء 5xx، ومكان العثور عليها في GSC، ومسار إصلاحها.
• إصلاح خطأ 500 داخلي في الخادم على موقعك (Kinsta) — قائمة إصلاح تفصيلية متمحورة حول استضافة WordPress (سجلات الخادم، الإضافات/السمات، ذاكرة PHP، .htaccess، الأذونات).
• أخطاء خادم 5xx: دليل العثور على مشكلات 5xx وإصلاحها (Lumar) — زاوية تدقيق مؤسسية/تقنية قوية في تأطير ملفات السجل وميزانية الزحف.
• إصلاح خطأ خادم 5xx في Google Search Console (Sitechecker) — شرح آخر لتقرير GSC.

فيديوهات

• Google Search Central (YouTube) — أرشيف SEO Office Hours، حيث تنشأ إرشادات John Mueller عن أخطاء الخادم والزحف (إطار إعادة المحاولة → الزحف البطيء → الإسقاط من الفهرس المذكور أعلاه). القناة

اختبر نفسك: 500 Internal Server Error

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

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