حالة 200 OK
ما معنى HTTP 200 OK وفقًا للمواصفة RFC 9110؟ ولماذا هو ضروري لكنه غير كافٍ للفهرسة؟ يشرح هذا المقال فخ soft 404، والفرق بين 200 و204 و304، وكيفية التأكد مما يتلقاه Googlebot فعليًا.
اللغات
دليل واحد في هذه الصفحة
- أداة مباشرة ذات صلةHTTP Status & Redirect Checker
HTTP 200 OK هو رمز النجاح القياسي من فئة 2xx وفقًا للمواصفة RFC 9110: عثر الخادم على المورد ويعيده. وهو الرمز الذي تريده لصفحة ويب، لكنه ضروري وليس كافيًا؛ تقول وثائق Google إن أنظمة الفهرسة 'may index the content, but that's not guaranteed' _(ترجمة)_ «قد تفهرس المحتوى، لكن ذلك غير مضمون». تُقيَّم الجودة والتكرار والمحتوى الرقيق وnoindex فوق حالة 200. والفخ الكلاسيكي هو soft 404: عنوان URL يعيد 200 بينما يبدو محتواه كخطأ أو صفحة فارغة، فتكتشفه Google على مستوى المحتوى وتعرضه كـsoft 404 في Search Console مهما كان الرمز. قارن بين 200 (نجاح مع جسم حقيقي) و204 (نجاح مع جسم فارغ، ويُعامل كـsoft 404) و304 (إشارة تخزين مؤقت لا قرار فهرسة). طابق الرمز مع الواقع: المحذوف ← 404 أو 410، والمنقول ← 301، والمكرر ← وسم canonical؛ وتحقق دائمًا مما تلقاه Googlebot نفسه عبر URL Inspection أو السجلات، لا مما يراه متصفحك فقط.
الخلاصة — تعني استجابة 200 OK أن الخادم يقول: «هذه هي الصفحة التي طلبتها، وكل شيء على ما يرام». إنه رمز النجاح الهادئ الذي تريده لكل صفحة ترغب في ظهورها في Google. لكن 200 وحده لا يضمن فهرسة الصفحة؛ فما زالت Google تنظر إلى ما إذا كان المحتوى يستحق الفهرسة. أما 200 في صفحة معطلة أو فارغة فعليًا فهو خلل، وليس ضوءًا أخضر.
ما معنى 200 OK؟
كلما طلب متصفحك أو Googlebot صفحة من خادم، يجيب الخادم برمز حالة من ثلاثة أرقام قبل أن يرسل أي شيء آخر. و200 OK هو رمز «كل شيء جيد»: وجد الخادم ما طلبته وأعاده، عادةً مع محتوى الصفحة. (تسمح المواصفة تقنيًا باستجابة 200 ذات جسم فارغ في بعض الحالات، لكن الصفحة التي تريد أن يقرأها الناس ينبغي أن تحمل جسمًا حقيقيًا دائمًا.) وهو الرمز الذي نادرًا ما تلاحظه لأنه يعني أن شيئًا لم يخطئ. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: IETF: RFC 9110 §15.3.1 — 200 OK
يلخص Patrick Stox الأمر في ثلاث كلمات في دليل Ahrefs لرموز حالة HTTP: “200 OK – All good. Everything is successful.” (ترجمة) «200 OK — كل شيء ناجح، ولا توجد مشكلة.»
بالنسبة إلى صفحات موقعك التي تريد أن يعثر عليها الناس في البحث، فإن 200 هو بالضبط الرمز الذي تريد أن تعيده.
لماذا لا تكفي حالة 200 وحدها؟
هذه هي النقطة التي تتجاوزها معظم صفحات «ماذا تعني 200؟»: تجعل 200 صفحتك مؤهلة للنظر في فهرستها، ولا تضمن دخولها إلى الفهرس. وهما أمران مختلفان جدًا.
فكّر في 200 بوصفها تذكرة تسمح لك بالدخول. بعد عبور الباب، تقرر Google ما إذا كان المحتوى يستحق الاحتفاظ به: هل جودته عالية؟ هل هو نسخة شبه مطابقة لصفحة أخرى؟ هل هو رقيق أو فارغ؟ هل يحتوي على وسم noindex يخبر Google أن تبقى خارجه؟ قد تمنع أي من هذه الحالات فهرسة صفحة 200 سليمة تمامًا.
لذلك، إذا أعادت الصفحة 200 لكنها لا تظهر في Google، فالمشكلة ليست في رمز الحالة؛ بل في المحتوى أو الإعداد.
الفخ: حالة 200 تعني «غير موجود» فعليًا
أخطر الأخطاء صفحة تعيد 200 بينما يقول محتواها «هذا غير موجود». ومن أمثلتها منتج نفد مخزونه مع صفحة فارغة، أو مقال محذوف ما زال يحمّل قالبًا فارغًا، أو صفحة نتائج بحث بلا نتائج؛ يرسل الخادم 200 مطمئنًا، لكن لا يوجد شيء حقيقي هناك.
تنظر Google إلى ما وراء الرمز، وتقرر من المحتوى الفعلي أن الصفحة فارغة أو تمثل خطأ، ثم تسميها soft 404 في Search Console، فتتعامل معها مثل صفحة «غير موجود» حقيقية. يتناول مقال soft-404-errors ذلك بتفصيل؛ والخلاصة القصيرة هي: إذا اختفت الصفحة فعلًا، فعليها أن تعيد 404 أو 410، لا 200.
القاعدة الوحيدة التي يجب تذكرها
يجب أن تعيد الصفحة التي تريدها في Google حالة 200 مع محتوى حقيقي. إذا اختفت الصفحة فاستخدم 404 أو 410. وإذا انتقلت فأعد توجيهها بـ301. وإذا كانت نسخة مكررة من صفحة أخرى فاستخدم وسم canonical. هل تريد صياغة Google الدقيقة، والفرق بين 200 و204، وكيفية التحقق مما تلقاه Googlebot؟ انتقل إلى تبويب Advanced.
الخلاصة — 200 OK هو رمز النجاح القياسي من فئة 2xx (RFC 9110 §15.3.1): نفّذ الخادم الطلب، وبالنسبة إلى GET وHEAD يكون الجسم تمثيلًا للمورد. وهو قابل للتخزين المؤقت استدلاليًا افتراضيًا. في SEO، هو ضروري لكنه غير كافٍ؛ إذ تقول وثيقة Google إن مسار الفهرسة “may index the content, but that’s not guaranteed,” (ترجمة) «قد يفهرس المحتوى، لكن ذلك غير مضمون»، لذلك تظل الجودة والتكرار والمحتوى الرقيق و
noindexعوامل حاسمة فوق 200. والفشل الكلاسيكي هو soft 404: حالة 200 تحيط بمحتوى خطأ أو محتوى فارغ، فتكتشفها Google على مستوى المحتوى وتعرضها كـsoft 404 مهما كان الرمز. قارن 200 (الجسم متوقع) بـ204 (جسم فارغ، ويُعامل كـsoft 404 في صفحات الويب) و304 (إشارة تخزين مؤقت لا قرار فهرسة). وتحقق مما تلقاه Googlebot؛ فقد تقدم قواعد إخفاء المحتوى وحظر الروبوتات والقواعد الجغرافية وإعدادات CDN/WAF رمزًا مختلفًا عن الذي يراه متصفحك.
ما معنى 200 في المواصفة؟
تُعد RFC 9110 (دلالات HTTP) المرجع الحالي، وتقول §15.3.1 بوضوح: “The 200 (OK) status code indicates that the request has succeeded.” (ترجمة) «يشير رمز حالة 200 (OK) إلى نجاح الطلب». ويعتمد محتوى الجسم على طريقة الطلب. وفي الطرق المهمة للصفحات، GET وHEAD، يكون المحتوى تمثيلًا للمورد المستهدف. وتوضح RFC أيضًا أنه، باستثناء استجابات CONNECT، يُتوقع أن تحمل استجابة 200 محتوى ما لم يشِر تأطير الرسالة صراحةً إلى طول صفري؛ لذلك فإن قول «200 لها جسم دائمًا» اختصار وليس قاعدة مطلقة. عمليًا، الصفحة التي تريد فهرستها ينبغي أن تحتوي على جسم حقيقي لا جسم فارغ. كما أن 200 «قابلة للتخزين المؤقت استدلاليًا» افتراضيًا ما لم يغيّر توجيه cache-control ذلك، ولهذا تهم رؤوس التحقق مثل ETag وLast-Modified في الصفحات التي يعاد الزحف إليها كثيرًا. Evidence for this claim RFC 9110 defines 200 OK as indicating that the request succeeded; the response content depends on the request method. Scope: HTTP semantics for 200 responses; this does not guarantee search indexing. Confidence: high · Verified: IETF: RFC 9110 §15.3.1 — 200 OK
من الناحية التقنية، لا تقتصر 200 على الصفحات. وتوضح RFC معنى «النجاح» لكل طريقة:
| طريقة الطلب | ما يمثله جسم 200 |
|---|---|
GET | المورد المستهدف |
HEAD | المورد المستهدف، لكن من دون نقل الجسم |
POST | حالة الإجراء أو نتيجته |
PUT، DELETE | حالة الإجراء |
OPTIONS | خيارات الاتصال بالمورد |
في الطرق غير GET، لن ترى 200 غالبًا؛ إذ تذكر MDN أن طلبات PUT أو DELETE الناجحة “often do not result in a 200 OK response,” (ترجمة) «غالبًا لا تؤدي إلى استجابة 200 OK»، وأن 201 Created أو 204 No Content أكثر شيوعًا. ولا شيء من ذلك مهم لـSEO في عناوين URL الخاصة بالصفحات؛ فالخلاصة التي ينبغي حملها هي أن 200 مع جسم حقيقي هي الهدف لوثيقة تريد فهرستها.
ضرورية وليست كافية للفهرسة
هذه أهم نقطة يجب ضبطها، وهي النقطة التي تخطئ فيها معظم صفحات المصطلحات المنافسة خطأً صريحًا. فهي تقول إن “200 means the page gets indexed.” (ترجمة) «200 تعني أن الصفحة ستُفهرس». لكن وثائق Google تقول خلاف ذلك. فبالنسبة إلى 200، Google “passes on whatever it received to the next processing step… For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (ترجمة) «توضح Google أن الاستجابة تنتقل إلى خطوة المعالجة التالية، وقد تصل إلى مسار الفهرسة دون ضمان إدراج المحتوى.» Evidence for this claim Google passes a 2xx response to its indexing pipeline, which may index the content but does not guarantee that it will do so; error-like content can be classified as a soft 404. Scope: Google Search handling of 2xx page responses and soft 404s. Confidence: high · Verified: Google: HTTP status codes and Search
إذًا، 200 عقد يتعلق باستجابة HTTP، وليست وعدًا بمصير الصفحة في البحث. وبعد 200، تقيّم Google بصورة مستقلة:
- الجودة — قد لا تُفهرس الصفحات الرقيقة أو منخفضة القيمة أو المُنشأة تلقائيًا.
- التكرار — قد تُدمج النسخة شبه المطابقة لعنوان URL أقوى في ذلك العنوان بدل فهرستها وحدها (وهذا ما يحاول وسم canonical التحكم فيه).
- التوجيهات — يمنع
noindexفي وسم meta أو رأسX-Robots-Tagالصفحة من الفهرسة حتى مع 200 مثالية.
يرسم دليل Patrick في Ahrefs الخط الفاصل نفسه على مستوى العائلة: “Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (ترجمة) «تسمح معظم رموز النجاح بفهرسة الصفحات، لكن الاستجابات بلا محتوى ستُعامل كحالات خطأ ناعمة ولن تُفهرس». تجعل 200 الصفحة مؤهلة؛ ولا تجعلها مفهرسة.
فخ soft 404
أوضح مثال على أن «200 لا تكفي» هو soft 404. وتقول وثيقة Google إن “200 isn’t the whole story” (ترجمة) «200 ليست الحكاية بأكملها». توضح وثيقة Google الخاصة برموز الحالة الآلية: “If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” (ترجمة) «إذا رأى بحث Google أن المحتوى يشير إلى خطأ، أو كان صفحة فارغة أو رسالة خطأ، فسيعرض Search Console خطأ soft 404.» لاحظ أن التصنيف يعتمد على المحتوى المعروض، لا على رمز HTTP. تنظر عملية فهرسة Google إلى ما وراء 200، وإذا بدا المحتوى كأنه “not found,” (ترجمة) «غير موجود،» يوضع في الفئة ويُعرض مثل 404 حقيقية.
ومن الحالات الواضحة: منتج متوقف يستمر في تحميل قالب فارغ، أو مقال محذوف ما زال يعيد غلاف 200، أو صفحة فئة مفلترة أو نتيجة بحث بلا عناصر مع رسالة “nothing here” (ترجمة) «لا شيء هنا». تعيد كل واحدة 200 صحيحة تقنيًا، لكنها تقول للمستخدمين وGoogle إنه لا يوجد ما يُرى.
يحتوي هذا الموقع على مقال مخصص عن soft-404-errors يتناول آليات الكشف والإصلاح؛ ولن أعيدها هنا. وخلاصة نقاش 200 هي ببساطة: إعادة 200 لصفحة اختفت فعلًا هي إعداد لظهور soft 404. والإصلاح أن تجعل الرمز مطابقًا للواقع.
فخ مرتبط: نجاح النقل ليس نجاح التطبيق
تستحق طبقة محدودة من التوضيح لأنها تظهر في دوائر API والمراقبة: قد تختلف طبقة HTTP عن طبقة التطبيق. قد يرسل endpoint في API حالة 200 مع كائن JSON للخطأ داخل الجسم؛ وقد ترسل الصفحة 200 بينما فشل اعتماد خلفي بصمت وأنتج كتلة معطلة بدل المحتوى الحقيقي. يقول سطر الحالة “delivered fine” (ترجمة) «تم التسليم بنجاح» — وهذا كل ما يدعيه. أما صحة الحمولة فعلًا فهي سؤال منفصل لا تجيب عنه حالة HTTP. ويختلف الممارسون فعلًا حول ما إذا كان ينبغي لـAPI الإبلاغ عن الخطأ برمز غير 200 أو بـ200 تحيط بحمولة خطأ؛ فهذا عقد تختاره كل فرقة، وليس قاعدة HTTP. وفي تركيز SEO لهذا الموقع، فإن النسخة الخاصة بالصفحات من المشكلة نفسها هي soft 404 أعلاه؛ والإصلاح متماثل في جوهره: لا تثق بسطر الحالة وحده، بل انظر إلى ما يحمله الجسم فعلًا.
200 مقابل 204 و304 — لا تخلط بينها
ثلاثة رموز يخلط الناس بينها، وواحد فقط منها هو نجاح “here’s your page” (ترجمة) «إليك الصفحة»:
| الرمز | الفئة | الجسم | المعنى | معالجة SEO |
|---|---|---|---|---|
200 OK | 2xx | يُتوقع محتوى حقيقي | نجاح — هذا هو المورد | مؤهل للفهرسة (غير مضمون) |
204 No Content | 2xx | فارغ عمدًا | نجاح بلا جسم عن قصد | يُعامل كـsoft 404 في عنوان URL لصفحة — راجع 204-no-content |
304 Not Modified | 3xx | لا يوجد | ”Use your cached copy” (ترجمة) «استخدم نسختك المخزنة مؤقتًا» (طلب مشروط) | إشارة تخزين مؤقت، لا قرار فهرسة |
إن 204 رمز نجاح حقيقي، لكن جسمها الفارغ لا يمنح الزاحف شيئًا يفهرسه، لذلك تقع في فئة soft 404 عند استخدامها في عنوان URL لصفحة (هذا مقال منفصل؛ لا تخلط حالة الجسم الفارغ مع 200 العادية). أما 304 فليست من العائلة نفسها أصلًا؛ فهي تجيب عن طلب مشروط (If-None-Match / If-Modified-Since) بإخبار العميل أن نسخته المخزنة مؤقتًا ما زالت حديثة. ولا تحمل جسمًا ولا تقول شيئًا عن الفهرسة؛ إنها آلية لكفاءة الزحف، وليست نسخة مكررة من 200. والسؤال الشائع “200 vs 304, aren’t those the same?” (ترجمة) «200 مقابل 304، أليستا الشيء نفسه؟» يخلط بين تحسين تخزين مؤقت واستجابة نجاح.
تحقق مما يراه Googlebot فعليًا
هذه فجوة تتجاوزها تقريبًا كل مقالة منافسة: قد تحصل جهات الطلب المختلفة على رموز مختلفة لعنوان URL نفسه. قد يرى متصفحك 200 نظيفة بينما يحصل Googlebot على شيء آخر؛ أحيانًا عمدًا (إخفاء المحتوى، وهو مخالفة للسياسات المزعجة في Google Search Essentials)، وغالبًا عن طريق الخطأ بسبب قواعد WAF أو حظر الروبوتات أو الاستهداف بحسب الموقع الجغرافي أو منطق حافة CDN أو إعداد اختبار A/B يفشل مع الروبوتات.
لذلك، فإن “it’s 200 in my browser” (ترجمة) «إنها 200 في متصفحي» ليست دليلًا على أن “Google sees 200.” (ترجمة) «ترى Google حالة 200». والتشخيص الصحيح هو التحقق مما تلقاه Googlebot نفسه:
- فحص عنوان URL في GSC — شغّل اختبارًا مباشرًا لرؤية الحالة والمحتوى المصيّر اللذين تجلبهما Google، لا ما يراه جهازك.
- سجلات الخادم أو CDN — الحقيقة المرجعية للرمز الذي حصل عليه كل user-agent فعليًا.
يفيد curl -I عادي من الطرفية، لكنه مجرد طالب آخر قد تصله قواعد حافة مختلفة عن Googlebot؛ اعتبره نقطة بيانات لا الكلمة الأخيرة.
كيف تفحص حالات النجاح وتراقبها؟
- أدوات مطور المتصفح — افتح تبويب Network، وأعد التحميل، وانقر على طلب المستند، ثم اقرأ عمود Status.
- سطر الأوامر — استخدم
curl -I https://example.com/pageلطلب واحد من الرؤوس، وcurl -ILلمتابعة سلسلة إعادة التوجيه. - Google Search Console — يعرض URL Inspection حالة الزحف ويتيح اختبارًا مباشرًا.
- Bing Webmaster Tools — أداة URL Inspection فيه هي طريقة Bing للتأكد مما تلقاه Bingbot. (لا تنشر Bing وثيقة مخصصة عن كيفية تأثير رموز الحالة في الفهرسة كما تفعل Google؛ ومن الأفضل قول ذلك بدل اختراع سياسة لـBing.)
- الزواحف — تعرض Screaming Frog وAhrefs Site Audit رموز الحالة على نطاق الموقع دفعة واحدة؛ كما يعرض شريط Ahrefs المجاني رمز الصفحة التي تزورها.
ما يبدو “healthy” (ترجمة) «سليمًا»: أن تعيد عناوين URL المهمة والمرجعية 200 باستمرار مع محتوى حقيقي، وأن تعيد الصفحات التي ينبغي أن تختفي أو تنتقل 404 أو 410 أو 301 بدل 200 مضللة.
القرار في سطر واحد
طابق الرمز مع الواقع. مطلوبة في الفهرس ← 200 مع محتوى جوهري. اختفت نهائيًا ← 404 أو 410 (راجع 404-not-found). انتقلت ← 301. نسخة مكررة من عنوان آخر ← أشر بوسم canonical إلى النسخة المفضلة بدل محاولة فرض رمز غير 200. إن 200 هي الضوء الأخضر للصفحات التي تستحق وجودها فعلًا؛ لا أكثر ولا أقل.
ملخص الذكاء الاصطناعي
خلاصة مركزة من نسخة Advanced:
- 200 OK هو رمز النجاح القياسي من فئة 2xx (RFC 9110 §15.3.1): نفّذ الخادم الطلب، وبالنسبة إلى GET وHEAD يمثل الجسم المورد. وهو قابل للتخزين المؤقت استدلاليًا افتراضيًا. وتقدم RFC الجسم بوصفه متوقعًا لا مطلقًا؛ فـ200 ذات طول صفري صالحة تقنيًا، لكن الصفحة التي تريد فهرستها تحتاج جسمًا حقيقيًا.
- ضرورية وليست كافية للفهرسة. تقول وثائق Google إن أنظمة الفهرسة “may index the content, but that’s not guaranteed.” (ترجمة) «قد تفهرس أنظمة الفهرسة المحتوى، لكن ذلك غير مضمون». وتُحكم الجودة والتكرار والمحتوى الرقيق و
noindexفوق 200. تخطئ معظم الصفحات المنافسة بقولها “200 = indexed.” (ترجمة) «200 = مفهرسة». - فخ soft 404: تُكتشف 200 المحيطة بمحتوى خطأ أو فارغ على مستوى المحتوى وتُعرض كـsoft 404 في Search Console — “if the content suggests an error… Search Console will show a
soft 404error.” (ترجمة) «إذا أوحى المحتوى بوجود خطأ… فستعرض Search Console خطأsoft 404». و200 لصفحة اختفت فعلًا هي إعداد لهذا الفخ. راجع مقال soft-404-errors. - فخ موازٍ: قد تختلف طبقة HTTP عن طبقة التطبيق؛ فقد تحيط 200 بحمولة خطأ في API أو بكتلة خلفية معطلة بصمت. يقول سطر الحالة إن النقل نجح فقط، لا إن الحمولة صحيحة.
- 200 مقابل 204 و304: 200 = نجاح مع جسم حقيقي (مؤهلة للفهرسة)؛ 204 = نجاح مع جسم فارغ، فتُعامل كـsoft 404 في عناوين الصفحات (راجع 204-no-content)؛ 304 = إشارة تخزين مؤقت لطلب مشروط، لا قرار فهرسة.
- تحقق مما تلقاه Googlebot. قد ترى جهات الطلب المختلفة رموزًا مختلفة بسبب إخفاء المحتوى أو حظر الروبوتات أو القواعد الجغرافية أو إعداد CDN/WAF. “200 in my browser” (ترجمة) «200 في متصفحي» ≠ “Google sees 200.” (ترجمة) «200 لدى Google». تحقق عبر اختبار URL Inspection المباشر في GSC أو سجلات الخادم، لا عبر المتصفح أو
curlفقط. - طابق الرمز مع الواقع: المطلوبة ← 200 مع محتوى حقيقي؛ المختفية ← 404/410؛ المنقولة ← 301؛ المكررة ← وسم canonical. وكما يقول Patrick: “200 OK – All good. Everything is successful” (ترجمة) «200 OK — نجاح كامل؛ كل شيء تم بنجاح»؛ وذلك لصفحة تستحق وجودها فعلًا.
الوثائق الرسمية
مراجع المصادر الأولية لمعنى 200 وكيفية تعامل Google معها.
مواصفة HTTP ومرجع المتصفح
- RFC 9110 §15.3.1 — 200 OK — التعريف المرجعي: نجح الطلب، مع دلالات الجسم بحسب الطريقة وقابلية التخزين المؤقت الاستدلالي.
- MDN — 200 OK — شرح مبسط، وقابلية التخزين المؤقت افتراضيًا، وتفصيل PUT/DELETE (تشيع 201/204 بدلًا منها).
Google Search Central
- كيف تؤثر رموز حالة HTTP وأخطاء الشبكة وDNS في بحث Google — لغة التعامل مع 2xx (“may index the content, but that’s not guaranteed” (ترجمة) «قد تفهرس أنظمة الفهرسة المحتوى، لكن ذلك غير مضمون») والإحالة إلى soft 404.
- أخطاء soft 404 — تقرير فهرسة الصفحات — تعريف Google لحالة 200 التي تمثل خطأ فعليًا، ولماذا تعد إعادة رمز نجاح لصفحة اختفت ممارسة سيئة.
- إخفاء المحتوى — سبب إمكانية تقديم رمز مختلف لGooglebot عن المستخدمين، ولماذا يعد ذلك مخالفة عند استخدامه للتلاعب بالترتيب.
Bing / Microsoft
- Bing Webmaster Tools — فحص عنوان URL — طريقة Bing للتأكد من استجابة HTTP التي تلقاها Bingbot (لا توجد وثيقة من Bing بعنوان “how status codes affect indexing” (ترجمة) «كيف تؤثر رموز الحالة في الفهرسة»).
اقتباسات من المصدر
عبارات موثقة من المصادر. كل رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.
مواصفة HTTP
- “The 200 (OK) status code indicates that the request has succeeded.” (ترجمة) «يشير رمز حالة 200 (OK) إلى نجاح الطلب.» — RFC 9110، دلالات HTTP، §15.3.1. اقرأ القسم
MDN Web Docs
- “The HTTP 200 OK success status response code indicates that a request has succeeded. A 200 OK response is cacheable by default.” (ترجمة) «تشير استجابة حالة النجاح HTTP 200 OK إلى نجاح الطلب. واستجابة 200 OK قابلة للتخزين المؤقت افتراضيًا.» انتقل إلى الاقتباس
Google Search Central — معالجة 2xx و200
-
“Google passes on whatever it received to the next processing step (which is product specific). For Google Search, the next system is the indexing pipeline. The indexing systems may index the content, but that’s not guaranteed.” (ترجمة) «تمرر Google كل ما تلقته إلى خطوة المعالجة التالية (وهي خاصة بالمنتج). وبالنسبة إلى Google Search، فإن النظام التالي هو مسار الفهرسة. وقد تفهرس أنظمة الفهرسة المحتوى، لكن ذلك غير مضمون.» — وثيقة Google عن رموز حالة HTTP، مدخل 200. وثيقة Google عن رموز الحالة
-
“If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a
soft 404error.” (ترجمة) «إذا أوحى المحتوى بوجود خطأ لدى Google Search، أو كان صفحة فارغة أو رسالة خطأ، فستعرض Search Console خطأsoft 404.» — الوثيقة نفسها، والإحالة الخاصة بـsoft 404. وثيقة Google عن رموز الحالة
Patrick Stox — Ahrefs
-
“200 OK – All good. Everything is successful.” (ترجمة) «200 OK — النتيجة: كل شيء ناجح.» — من دليل رموز حالة HTTP على مدونة Ahrefs. انتقل إلى الاقتباس
-
“Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed.” (ترجمة) «تسمح معظم رموز النجاح بفهرسة الصفحات، لكن الاستجابات بلا محتوى ستُعامل كأخطاء ناعمة ولن تُفهرس.» — من الدليل نفسه، عن كيفية تعامل Google مع عائلة 2xx. انتقل إلى الاقتباس
200 OK — مرجع سريع
ما هي؟
| الرمز | 200 OK |
| الفئة | 2xx (نجاح) |
| المواصفة | RFC 9110 §15.3.1 |
| الجسم | يُتوقع محتوى حقيقي (لـGET/HEAD) |
| قابلة للتخزين المؤقت؟ | نعم — قابلة للتخزين المؤقت استدلاليًا افتراضيًا |
| حالة SEO | مؤهلة للفهرسة — غير مضمونة |
200 مقابل الأشقاء المربكين
| الرمز | الفئة | الجسم | الاستخدام الصحيح | معالجة SEO |
|---|---|---|---|---|
200 OK | 2xx | محتوى حقيقي | صفحة تريد فهرستها | مؤهلة للفهرسة (غير مضمونة) |
204 No Content | 2xx | فارغ عمدًا | واجهات API وbeacons — ليست صفحة أبدًا | تُعامل كـsoft 404 في عناوين الصفحات |
304 Not Modified | 3xx | لا يوجد | تخزين مؤقت لطلب مشروط | إشارة تخزين مؤقت، لا قرار فهرسة |
404 Not Found | 4xx | أي محتوى | صفحة اختفت | تُسقط من الفهرس بمرور الوقت |
410 Gone | 4xx | أي محتوى | صفحة أزيلت نهائيًا | مثل 404؛ قد تكون الديمومة أسرع قليلًا |
301 Moved Permanently | 3xx | — | صفحة انتقلت | تمرر إشارة canonical إلى الوجهة |
أي رمز ينبغي أن يعيده عنوان URL هذا؟
- مطلوب في الفهرس ←
200مع محتوى حقيقي جوهري. - اختفى نهائيًا ←
404أو410(راجع 404-not-found). - انتقل إلى عنوان جديد ←
301. - نسخة مكررة من عنوان آخر ← أبقِ 200 وأضف وسم canonical إلى النسخة المفضلة.
- فارغ عمدًا (API أو beacon) ←
204(راجع 204-no-content) — ليس لصفحة أبدًا.
حقائق سريعة
- تجعل 200 الصفحة مؤهلة للفهرسة، لا مفهرسة؛ تقرر Google بصورة منفصلة بحسب الجودة والتكرار والمحتوى الرقيق و
noindex. - إن 200 في صفحة اختفت أو فرغت فعليًا هي soft 404 في نظر Google.
- قد ترى جهات الطلب المختلفة رموزًا مختلفة لعنوان URL واحد؛ تحقق مما تلقاه Googlebot عبر URL Inspection في GSC أو سجلات الخادم، لا عبر المتصفح أو
curlفقط. - افحص الرموز باستخدام: تبويب Network في DevTools، و
curl -I/curl -IL، وURL Inspection في GSC/Bing، وScreaming Frog، وAhrefs Site Audit/Toolbar.
خرافات شائعة عن 200 OK
«رمز حالة 200 يعني أن الصفحة مفهرسة».
هذا خطأ. تعني 200 أن الخادم أعاد المحتوى بنجاح؛ أما الفهرسة فهي قرار لاحق منفصل. تقول وثيقة Google إن أنظمة الفهرسة “may index the content, but that’s not guaranteed.” (ترجمة) «قد تفهرس المحتوى، لكن ذلك غير مضمون». وتُقيَّم الجودة والتكرار والمحتوى الرقيق وnoindex فوق 200.
«إذا عرضت Search Console soft 404، فخادمي معطل». ليس بالضرورة. soft 404 ليست رمزًا يرسله خادمك؛ بل تسمية تطبقها Google بسبب عدم التطابق بين حالة 200 ومحتوى يقرأ كخطأ أو صفحة فارغة. ينفذ الخادم ما أُعد له بالضبط (إرسال 200)؛ المشكلة في المحتوى لا في الرأس.
«200 جيدة دائمًا، وانتهى الأمر». ليس دائمًا. إن 200 لعنوان URL كان ينبغي أن يعيد 404 — مثل منتج محذوف أو عرض منتهي أو صفحة نتائج بحث فارغة — سيئة فعليًا. فهي تدعو إلى معاملة soft 404 وقد تهدر جهد الزحف في إعادة زيارة عنوان URL لا يقدم شيئًا.
«يعرض متصفحي 200، إذًا ترى Google 200 بالتأكيد». هذا غير مضمون. قد تقدم قواعد حظر الروبوتات أو إخفاء المحتوى أو الموقع الجغرافي أو إعداد CDN/WAF استجابة مختلفة لـGooglebot عن الاستجابة التي يراها مستخدم بشري. تحقق عبر URL Inspection أو سجلات الخادم.
«200 و204 متشابهتان عمليًا؛ كلتاهما تعنيان النجاح». كلتاهما من فئة 2xx، لكن 204 تحمل جسمًا فارغًا عن قصد. وهذا مناسب لواجهات API وbeacons، وخاطئ لصفحة تريد فهرستها؛ إذ تُعامل 204 في عنوان URL لصفحة كـsoft 404 (راجع 204-no-content).
«200 مقابل 304 — أليستا الفكرة نفسها؟»
لا. إن 304 Not Modified آلية تخزين مؤقت تجيب عن طلب مشروط (If-None-Match / If-Modified-Since) وتخبر العميل باستخدام نسخته المخزنة مؤقتًا. لا تحمل جسمًا وليست قرار فهرسة؛ إنها مفهوم مختلف عن 200.
لماذا قد تفشل صفحة 200 رغم سلامتها؟
تسمي Search Console عنوان URL soft 404
العَرَض: يعيد عنوان URL حالة 200، لكن تقرير فهرسة الصفحات يعرضه كـsoft 404.
السبب المحتمل: يبدو جسم الاستجابة فارغًا أو معطلًا أو كأنه صفحة خطأ. ومن الحالات الشائعة منتج متوقف بلا معلومات مفيدة، أو مقال محذوف داخل قالب مكتمل، أو صفحة بحث بلا نتائج.
الإصلاح: طابق الاستجابة مع الواقع. استعد محتوى جوهريًا إذا كان ينبغي للصفحة أن توجد، أو أعد 404 أو 410 إن اختفت، أو استخدم 301 إن انتقلت. أعد تشغيل الاختبار المباشر في URL Inspection وتأكد من تطابق الاستجابة والمحتوى المصيّر.
يحصل متصفحك على 200 لكن لا يحصل Googlebot عليها
العَرَض: تعرض DevTools أو curl حالة 200، بينما لا تستطيع Google جلب عنوان URL أو فهرسته.
السبب المحتمل: تقدم CDN أو WAF أو قاعدة جغرافية أو قاعدة روبوتات أو تجربة استجابة مختلفة لـGooglebot. طلبك أنت ليس دليلًا على طلب Google.
الإصلاح: قارن بين طلب عادي وطلب باستخدام user-agent الخاص بـGooglebot، ثم افحص URL Inspection وسجلات URL/CDN. صحح قاعدة الحافة وتأكد عبر الاختبار المباشر من وصول 200 إلى Googlebot مع الجسم الجوهري نفسه الذي يراه المستخدمون.
الصفحة 200 لكنها لا تزال غير مفهرسة
العَرَض: رمز الحالة سليم، لكن عنوان URL ما زال مستبعدًا من الفهرس.
السبب المحتمل: تجعل 200 المحتوى مؤهلًا للمعالجة فقط. وقد تمنعه توجيهة noindex أو تعارض تكرار/canonical أو محتوى منخفض القيمة من دخول الفهرس.
الإصلاح: توقف عن تغيير رمز الحالة. افحص توجيهات الفهرسة، وcanonical الذي اختارته Google، والمحتوى الفعلي. فالاستجابة الناجحة من HTTP ليست حكمًا على الفهرسة.
استجابات 200 تحكي قصة خاطئة
هذه أمثلة مبسطة. سطر الحالة ناجح تقنيًا، لكن الجسم هو الذي يحدد ما إذا كان ذلك النجاح صادقًا.
غلاف منتج فارغ: 200 مضللة
HTTP/1.1 200 OK
Content-Type: text/html
<h1>Product unavailable</h1>
<p>There is nothing here.</p>إذا اختفى المنتج نهائيًا بلا بديل، فأعد 404 أو 410. وإذا بقيت صفحة منتج مفيدة — مواصفات أو بدائل أو معلومات دعم أو إتاحة — فقد تظل 200 مناسبة لأن للصفحة غرضًا حقيقيًا.
مقال محذوف مع بديل: استخدم إعادة توجيه
HTTP/1.1 301 Moved Permanently
Location: https://example.com/current-guideصفحة 200 قالبية تقول “article deleted” (ترجمة) «المقال محذوف» تترك المستخدمين بلا وجهة وتدعو إلى تصنيف soft 404. وينبغي أن تكون الوجهة لبديل ذي صلة هي إعادة توجيه 301 من جانب الخادم.
بحث داخلي بلا نتائج: مفيد أم فارغ؟
قد تكون 200 صادقة عندما تساعد الصفحة المستخدمين على إعادة صياغة البحث أو تصفح الفئات أو العثور على بدائل. أما صفحة رقيقة لا تحتوي إلا على “0 results” (ترجمة) «0 نتيجة» فتبدو كخطأ رغم رمز النجاح. والفارق هو فائدة الجسم، لا الرقم 200.
فرز استجابات 200 المشبوهة
ألصق تصدير زحف يحتوي على URL ورمز الحالة والعنوان وcanonical وقابلية الفهرسة وعينة قصيرة من نص الجسم. يفصل هذا الطلب بين نجاح HTTP ومشكلات المحتوى والفهرسة.
You are auditing URLs that return HTTP 200. Review the pasted rows without assuming that
"200" means "indexed" or "healthy."
For each URL:
1. Classify it as a substantive page, likely soft 404, redirect-needed page, genuinely gone
page, duplicate/canonical case, or needs manual review.
2. Cite the exact evidence from the supplied title, body sample, canonical, and directives.
3. Recommend one response: keep 200, restore content, 301 to a relevant replacement,
return 404/410, or fix canonical/noindex signals.
4. Flag any conclusion that cannot be made from the supplied data.
Do not invent page content, redirect targets, or indexing status. End with a prioritized
manual-check list.
PASTE CRAWL ROWS HERE افحص الاستجابة بدل الثقة بالصفحة
افحص استجابة واحدة باستخدام curl
شغّل هذه الأوامر على macOS أو Linux أو WSL. يقرأ الأمر الأول رؤوس الاستجابة، بينما ينزل الثاني الجسم أيضًا حتى تتحقق من أن 200 تحتوي محتوى حقيقيًا.
curl -sI https://example.com/page
curl -sS -D - https://example.com/page -o page.htmlابحث عن سطر حالة 200، ثم افتح page.html. لا تستطيع الرؤوس وحدها كشف soft 404.
قارن طلبًا عاديًا بطلب باستخدام user-agent الخاص بـGooglebot
url="https://example.com/page"
curl -sS -o /dev/null -w "default: %{http_code} %{size_download} bytes\n" "$url"
curl -sS -A "Googlebot" -o /dev/null -w "Googlebot UA: %{http_code} %{size_download} bytes\n" "$url"يمثل الاختلاف سببًا لفحص قواعد CDN/WAF، وليس دليلًا على أن Googlebot نفسه تلقى استجابة الطلب المزيف. أكد الجلب الحقيقي عبر URL Inspection.
افحص قائمة من الاستجابات غير 200
ضع عنوان URL واحدًا في كل سطر في urls.txt:
while IFS= read -r url; do
curl -sS -o /dev/null -w "%{http_code}\t%{url_effective}\n" "$url"
done < urls.txtيكشف هذا حالات عدم تطابق واضحة في الحالة. ولا يستطيع الحكم على ما إذا كان جسم 200 جوهريًا، لذلك تابع فحص القوالب المشبوهة وتقارير soft 404.
أدوات للتحقق من استجابات 200
أداة Patrick المجانية
- Bulk HTTP Status Code Checker — ألصق ما يصل إلى 500 عنوان URL لجمع رموز الحالة والوجهات النهائية وسلاسل إعادة التوجيه وزمن الاستجابة في تصدير واحد. استخدمها للعثور على العناوين التي لا تعيد
200فعليًا؛ ثم افحص الجسم وSearch Console منفصلين لاكتشاف الأخطاء الناعمة، لأن أداة فحص الحالة لا تستطيع الحكم على جودة المحتوى والفهرسة.
أدلة محركات البحث والخادم
- Google Search Console URL Inspection — قارن النتيجة المفهرسة بالجلب المباشر وراجع المحتوى المصيّر الذي تستطيع Google الوصول إليه.
- Bing Webmaster Tools URL Inspection — تحقق من الاستجابة التي يقول Bingbot إنه تلقاها.
- سجلات الخادم وCDN — أكد رمز الحالة الذي تلقته طلبات الزحف الحقيقية؛ فالسجلات أدلة أقوى من تغيير user-agent في
curl. - لوحة Network في أدوات مطور المتصفح — تحقق من طلب المستند ورؤوس الاستجابة والجسم في جلسة المتصفح أمامك.
اختبر نفسك: 200 OK
خمسة أسئلة سريعة عن معنى 200. اختر إجابة كل سؤال ثم تحقق منها.
سجل التغييرات
تم التحديث في 22 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 7 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 7 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 6 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 6 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 6 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 5 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 17 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
Try it live
This is a real endpoint on this site — not a simulation.
Hit it from the button, open it in a new tab, or
curl -i it from your terminal, and the server answers with the actual status code this article is about.