تدقيق سلامة رموز الحالة

أطر العمل الحديثة تقدّم 200 لكل شيء تقريبًا، فيبدو المنتج المحذوف ونتيجة الفلترة الفارغة والاستدعاء الفاشل لطرف ثالث كلها صفحات سليمة أمام الزاحف. عندها يضطر Google إلى التخمين عبر كشف soft 404، وهو بطيء وغير موثوق. والحل الانعكاسي بإضافة noindex خاطئ في معظم هذه الحالات، لأنه يُبقي الرابط في طابور الزحف إلى ما لا نهاية بدل إزالته.

ملف المهارة

---
name: status-code-integrity-audit
description: استخدمها عندما تعيد الصفحات المحذوفة أو الفارغة أو الفاشلة رمز 200 OK، أو عندما تظهر أخطاء soft 404 في Search Console، أو قبل إزالة دفعة من الروابط من الموقع.
---

# تدقيق سلامة رموز الحالة

أطر العمل الحديثة تقدّم 200 لكل شيء تقريبًا، فيبدو المنتج المحذوف ونتيجة الفلترة الفارغة والاستدعاء الفاشل لطرف ثالث كلها صفحات سليمة أمام الزاحف. عندها يضطر Google إلى التخمين عبر كشف soft 404، وهو بطيء وغير موثوق. والحل الانعكاسي بإضافة noindex خاطئ في معظم هذه الحالات، لأنه يُبقي الرابط في طابور الزحف إلى ما لا نهاية بدل إزالته.

## ما تحتاجه أولًا

- تصدير زحف يتضمن رموز الحالة، إضافة إلى قائمة soft 404 من Search Console
- قائمة بكل حالة يستطيع التطبيق إنتاجها بلا محتوى مفيد، مأخوذة من الكود أو من المطورين لا من زحف
- وصول عبر سطر الأوامر لطلب الروابط وقراءة ترويسات الاستجابة الخام
- القدرة على تغيير رموز الحالة داخل التطبيق ورؤية ما يفعله الـ CDN بها

## الطريقة

1. أحصِ حالات الفشل من قاعدة الكود مع المطورين: عنصر محذوف، ونتيجة بحث أو فلترة فارغة، وإعلان منتهٍ، ومنتج نفد نهائيًا، وصفحة خلف تسجيل الدخول، واعتماد على API فشل. الزحف لا يجد إلا الحالات المرتبطة أصلًا، وهي أقلها.
2. اطلب رابطًا واحدًا عن كل حالة من سطر الأوامر وسجّل رمز الحالة في الترويسة، لا ما يقوله متن الصفحة. صفحة يقول متنها إن العنصر غير موجود بينما ترسل 200 هي أكثر ما يظهر في هذا التدقيق، وهي غير مرئية داخل المتصفح.
3. خصّص الرمز الصحيح لكل حالة: 404 حين يكون الشيء قد زال ولا بديل له، و410 حين تكون واثقًا وتريد إزالة أسرع، و301 حين يوجد بديل حقيقي واحد لواحد، و200 مع محتوى فعلي حين تظل الصفحة تؤدي غرضًا، و503 مع Retry-After لفترات التوقف المخططة.
4. افحص ما يحدث تحت الحمل وأثناء فشل الاعتماديات. الخادم الذي يجيب بـ 200 مع صفحة خطأ يخفي انقطاعًا عن المراقبة وعن Google، بينما الـ 503 الصحيح يجعل الزحف يتراجع ثم يستأنف دون خسارة في الفهرس.
5. طابق القائمة مع تقرير soft 404. كل مدخل هناك هو تصريح من Google بأنه لا يوافق على الـ 200 الذي أرسلته، وهو أرخص تأكيد ستحصل عليه على أن حالة ما مصنفة خطأ.
6. تحقق على مستوى الترويسة بعد النشر، لأن edge worker أو قاعدة تخزين مؤقت أو صفحة خطأ مخصصة قد تعيد كتابة رمز حالة ضبطه التطبيق بشكل صحيح، وستُظهر سجلات التطبيق الرمز الصحيح.
7. راقب إحصاءات الزحف أسبوعين. دفعة كبيرة من أخطاء 404 أو 410 الجديدة تنتج رسمًا بيانيًا مقلقًا لكنه متوقع ويصحح نفسه؛ أما ارتفاع أخطاء 5xx في النافذة نفسها فليس كذلك ويجب إيقافه.

## ما الذي تنتجه

خريطة رموز استجابة حالة بحالة تبيّن الرمز الحالي والصحيح لكل واحدة، وفحص موثق على مستوى الترويسة يؤكد ما ترسله بيئة الإنتاج فعلًا.

## أين تخطئ عادةً

- إعادة توجيه كل صفحة محذوفة إلى الصفحة الرئيسية، وهو ما يعامله Google كـ soft 404 على أي حال بينما يدمّر الإشارة الدالة على أن الصفحة زالت
- تقديم 200 مع noindex على حالة فارغة، فيبقى الرابط في طابور الزحف إلى الأبد ولا يغادره أبدًا
- الاختبار داخل المتصفح، حيث يستطيع موجّه من جهة العميل أو service worker عرض صفحة 404 سُلّمت بترويسة 200
- الإجابة بـ 404 أثناء نافذة صيانة بدل 503، فتخرج صفحات سليمة من الفهرس من أجل ساعة واحدة

---

من مكتبة مهارات QuQi - https://www.quqi.io/ar/skills/status-code-integrity-audit

ما تحتاجه أولًا

• تصدير زحف يتضمن رموز الحالة، إضافة إلى قائمة soft 404 من Search Console
• قائمة بكل حالة يستطيع التطبيق إنتاجها بلا محتوى مفيد، مأخوذة من الكود أو من المطورين لا من زحف
• وصول عبر سطر الأوامر لطلب الروابط وقراءة ترويسات الاستجابة الخام
• القدرة على تغيير رموز الحالة داخل التطبيق ورؤية ما يفعله الـ CDN بها

الطريقة

1. 01 أحصِ حالات الفشل من قاعدة الكود مع المطورين: عنصر محذوف، ونتيجة بحث أو فلترة فارغة، وإعلان منتهٍ، ومنتج نفد نهائيًا، وصفحة خلف تسجيل الدخول، واعتماد على API فشل. الزحف لا يجد إلا الحالات المرتبطة أصلًا، وهي أقلها.
2. 02 اطلب رابطًا واحدًا عن كل حالة من سطر الأوامر وسجّل رمز الحالة في الترويسة، لا ما يقوله متن الصفحة. صفحة يقول متنها إن العنصر غير موجود بينما ترسل 200 هي أكثر ما يظهر في هذا التدقيق، وهي غير مرئية داخل المتصفح.
3. 03 خصّص الرمز الصحيح لكل حالة: 404 حين يكون الشيء قد زال ولا بديل له، و410 حين تكون واثقًا وتريد إزالة أسرع، و301 حين يوجد بديل حقيقي واحد لواحد، و200 مع محتوى فعلي حين تظل الصفحة تؤدي غرضًا، و503 مع Retry-After لفترات التوقف المخططة.
4. 04 افحص ما يحدث تحت الحمل وأثناء فشل الاعتماديات. الخادم الذي يجيب بـ 200 مع صفحة خطأ يخفي انقطاعًا عن المراقبة وعن Google، بينما الـ 503 الصحيح يجعل الزحف يتراجع ثم يستأنف دون خسارة في الفهرس.
5. 05 طابق القائمة مع تقرير soft 404. كل مدخل هناك هو تصريح من Google بأنه لا يوافق على الـ 200 الذي أرسلته، وهو أرخص تأكيد ستحصل عليه على أن حالة ما مصنفة خطأ.
6. 06 تحقق على مستوى الترويسة بعد النشر، لأن edge worker أو قاعدة تخزين مؤقت أو صفحة خطأ مخصصة قد تعيد كتابة رمز حالة ضبطه التطبيق بشكل صحيح، وستُظهر سجلات التطبيق الرمز الصحيح.
7. 07 راقب إحصاءات الزحف أسبوعين. دفعة كبيرة من أخطاء 404 أو 410 الجديدة تنتج رسمًا بيانيًا مقلقًا لكنه متوقع ويصحح نفسه؛ أما ارتفاع أخطاء 5xx في النافذة نفسها فليس كذلك ويجب إيقافه.

ما الذي تنتجه

خريطة رموز استجابة حالة بحالة تبيّن الرمز الحالي والصحيح لكل واحدة، وفحص موثق على مستوى الترويسة يؤكد ما ترسله بيئة الإنتاج فعلًا.

أين تخطئ عادةً

• إعادة توجيه كل صفحة محذوفة إلى الصفحة الرئيسية، وهو ما يعامله Google كـ soft 404 على أي حال بينما يدمّر الإشارة الدالة على أن الصفحة زالت
• تقديم 200 مع noindex على حالة فارغة، فيبقى الرابط في طابور الزحف إلى الأبد ولا يغادره أبدًا
• الاختبار داخل المتصفح، حيث يستطيع موجّه من جهة العميل أو service worker عرض صفحة 404 سُلّمت بترويسة 200
• الإجابة بـ 404 أثناء نافذة صيانة بدل 503، فتخرج صفحات سليمة من الفهرس من أجل ساعة واحدة

استخدم هذه المهارة في الذكاء الاصطناعي الخاص بك

الملف الذي تنزّله markdown بسيط، يحمل الاسم والمُشغّل في ترويسته. وحين يكون المساعد قادرًا على تحميل المهارات وحده، فهذه الترويسة هي ما يقرؤه ليقرر أن هذه المهارة تنطبق.

المزيد في SEO التقني