تخطَّ إلى المحتوى
مشكلات ووردبريس

تشخيص 404 للمقالات بعد نقل ووردبريس: فحص الروابط الدائمة وقواعد المسارات

محمد التتر 6 دقائق قراءة 116 مشاهدة
تقرير مقال حقيقي يعيد 200 ومسار وهمي يعيد 404 بعد توليد القواعد


الصفحة الرئيسية تعمل بعد نقل الموقع، لكن المقالات تعرض 404 رغم وجودها في لوحة التحكم؟ ابدأ بفحص الروابط الدائمة قبل إعادة استيراد المقالات. نشرح أولًا خطوات التشخيص، ثم نوثّق تجربة مستقلة على Apache أعادت إنتاج سبب محدد للعطل وإصلاحه، ونوضح متى تحتاج إلى دعم الاستضافة.

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

أول اختبارين

  1. جرب عنوان موقعك متبوعا بـ/?p=35 مع استبدال 35 برقم مقال موجود لديك؛ تجده في رابط صفحة تحريره بعد post=. إذا عمل هذا الشكل وتعطل الرابط المعتاد، فهذه قرينة على مشكلة توجيه الروابط. راقب عنوان النهاية وسلسلة التحويل: قد يحوّل ووردبريس رابط الرقم إلى الرابط الدائم المعطّل؛ ففشل الاثنين لا يثبت اختفاء المحتوى.
  2. اذهب إلى الإعدادات ← الروابط الدائمة واضغط حفظ مرة واحدة دون تغيير البنية. هذا يعيد توليد قواعد ووردبريس.

إذا عرضت اللوحة رسالة أن .htaccess غير قابل للكتابة، لا تفتح الصلاحيات للجميع. انسخ القواعد التي يعرضها ووردبريس وأرسلها للاستضافة أو ضعها عبر مدير ملفات موثوق. على Nginx لا يعمل .htaccess أصلا؛ تحتاج قاعدة في إعداد الخادم. أما اختبار أغسطس أدناه فاستخدم خادم PHP محليًا مع Router مخصص، لذلك نتيجته البالغة 95 قاعدة لا تثبت إعداد Apache في الاستضافة. توجد لاحقًا تجربة مستقلة على Apache بتاريخ 22 سبتمبر.

إذا لم يكف حفظ الروابط

إذا لم يكف الحفظ، أرسل المشكلة إلى دعم الاستضافة. اطلب فحص إعدادات تحويل الروابط المناسبة لخادمهم: mod_rewrite وAllowOverride في Apache، أو تمرير الطلبات إلى index.php في Nginx. اطلب أيضا التأكد من مجلد الموقع الذي يخدم النطاق فعلا (Document Root)؛ فقد يكون ملف .htaccess الذي تراجعه في مجلد آخر. امسح Cache الخادم بعد تعديل القاعدة، واختبر مقالا واحدا ومسارا وهميا.

تجنب تحويل كل 404 إلى الرئيسية

قاعدة عامة تعيد كل رابط مفقود إلى / قد تجعل الموقع يبدو «عاملا»، لكنها تخفي الأخطاء وقد تُصنّف بعض هذه الصفحات على أنها Soft 404؛ الحكم النهائي لمحرك البحث لا لرمز التحويل وحده. يجب أن يعمل الرابط الحقيقي فقط، ويبقى الوهمي 404. يوضح اختبار 404 الحقيقية وSoft 404 سبب هذه المقارنة.

بعد نقل الدومين

حدث home وsiteurl والروابط المتسلسلة بأداة آمنة، ثم احفظ الروابط الدائمة. افحص الصور والقوائم وREST API أيضا، لأن نجاح المقال لا يضمن تحديث كل عنوان قديم. لا تغير الأجزاء الأخيرة من روابط المقالات المنشورة جماعيا؛ وإن تغير رابط له مقابل حقيقي فاستخدم 301 إلى المقابل فقط.

فحص مسارات سليمة: ما يثبته وما لا يثبته

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

تاريخ التجربة: 19 أغسطس 2026؛ ووردبريس: 7.0.4؛ PHP: 8.3.30؛ مكان التنفيذ وأدواته: بنية /%postname%/ وخادم PHP Router محلي.

كان مخزن Rewrite يحتوي 95 قاعدة قبل التوليد وبعده. أعاد مقال حقيقي HTTP 200، بينما أعاد مسار وهمي HTTP 404؛ أي إن التوجيه يميز الموجود من المفقود.

تقرير مقال حقيقي يعيد 200 ومسار وهمي يعيد 404 بعد توليد القواعد
تقرير مقال حقيقي يعيد 200 ومسار وهمي يعيد 404 بعد توليد القواعد — تجربة GZ تقنية بتاريخ 19 أغسطس 2026.

تحقق إضافي، 19 أغسطس 2026: قرأنا البنية، أعدنا توليد rewrite rules دون كتابة .htaccess، ثم قارنّا مقالًا حقيقيًا بمسار وهمي. أعدنا توليد قواعد ووردبريس وفحصنا مسارين في المختبر. لا تثبت النتيجة إصلاح إعداد Apache أو Nginx على استضافة أخرى؛ يلزم اختبار المسارات بعد النقل.

بطاقة دليل أصلية من إعادة التحقق المحلية لمقال المقالات تعيد 404 بعد النقل أو تغيير الروابط الدائمة، وتعرض طريقة الاختبار والنتيجة المقاسة.
اختبار محلي مستقل — 19 أغسطس 2026: القواعد قبل/بعد: 95/95 — المقال: HTTP 200 — الوهمي: HTTP 404

تجربة جديدة: مقال موجود يفشل على Apache ثم يعمل بعد تصحيح الإعداد

تاريخ التنفيذ: 22 سبتمبر 2026. البيئة: Apache 2.4.66 على Windows، ووردبريس 7.1، PHP 8.3.30، MySQL 8.4.3. أنشأنا موقع اختبار محليًا ببيانات اصطناعية وقالب Twenty Twenty-Five، دون نسخ بيانات الزوار أو إعدادات الموقع الحي.

هذه تجربة مستقلة عن فحص أغسطس أعلاه. نشرنا مقال عينة بالرقم 4 والرابط /rewrite-proof-20260921/، وبنية روابط /%postname%/. كان ملف .htaccess يحتوي قواعد ووردبريس، وكانت وحدة mod_rewrite محمّلة، لكن إعداد مجلد الموقع في Apache احتوى AllowOverride None، فتجاهل الملف.

كيف أثبتنا أن المحتوى موجود قبل الإصلاح؟

قرأنا حالة المقال من قاعدة المختبر، ثم طلبنا /index.php?rest_route=/wp/v2/posts/4. أعاد الطلب HTTP 200، والحالة publish، ونص العينة نفسه في الحالتين. هذا المسار يمر عبر ملف index.php الموجود مباشرة، ولا يحتاج توجيه الرابط الجميل. كما بقيت الرئيسية تعمل.

إذا كانت REST API محمية أو معطلة في استضافتك، فلا تعتبر رفض هذا الطلب دليلًا على حذف المقال، ولا تلغِ الحماية لمجرد تقليد الاختبار. تحقّق من وجود المقال وحالته في لوحة التحكم واستعن بالدعم.

التغيير والنتيجة المقاسة

  • قبل: رابط المقال الجميل أعاد 404. رابط /?p=4 أعاد 301 إلى الرابط الجميل، ثم 404؛ لذا لم يكن بديلًا يعمل في هذه العينة.
  • التغيير: في إعداد مجلد المختبر نفسه، استبدلنا AllowOverride None بـAllowOverride FileInfo، ثم أعدنا تشغيل Apache بالإعداد الجديد. لم نغيّر بنية الروابط أو محتوى المقال، ولم نعد حفظ الروابط الدائمة بين القياسين.
  • بعد: رابط المقال أعاد 200 واحتوى نص العينة. وأصبحت سلسلة رابط الرقم 301 ثم 200.
  • اختبار مضاد: بقي المسار الوهمي يعيد 404 قبل التصحيح وبعده؛ لم نستخدم تحويلًا عامًا إلى الرئيسية.
سجل مقارنة مختصر 
test date: 2026-09-22
server: Apache 2.4.66 / Windows
WordPress 7.1; PHP 8.3.30; MySQL 8.4.3
before: AllowOverride None
  home: 200
  direct REST post 4: 200, publish, expected content present
  pretty post URL: 404
  ?p=4 redirect chain: 301 -> 404
  nonexistent URL: 404
after: AllowOverride FileInfo
  home: 200
  direct REST post 4: 200, publish, expected content present
  pretty post URL: 200, expected content present
  ?p=4 redirect chain: 301 -> 200
  nonexistent URL: 404
WordPress rewrite rules: 94 -> 94, hash unchanged
post content and .htaccess: hashes unchanged

ماذا تفعل إذا كانت لديك لوحة ووردبريس فقط؟ أرسل للدعم رابط مقال متأثر ورقمه، وحالة نشره، وسلسلة التحويل إن ظهرت. اطلب فحص مجلد الموقع الفعلي وقراءة قواعد التوجيه. إعداد AllowOverride يخص Apache، وليس خانة تُلصق في محرر ووردبريس؛ قد تختار الاستضافة وضع قواعد التوجيه في إعداد الخادم مباشرة بدل السماح بملفات .htaccess.

حدود التجربة: أثبتنا سببًا واحدًا وإصلاحه في مختبر Apache، لا كل أسباب 404 ولا إعداد Nginx أو الاستضافة الحالية. ثبات عدد قواعد ووردبريس وحده لا يثبت سلامة إعداد الخادم. أوقفنا خادمي المختبر بعد القياس، ولم نعدّل إعدادات الموقع الحي.

مرجع الإعداد: Apache: AllowOverride، وقواعد Apache الأساسية لووردبريس.

المصادر

أدلة مرتبطة تساعدك في الخطوة التالية


#الروابط والتحويلات #النسخ الاحتياطي والاستعادة #تشخيص الأخطاء
شارك:

محمد التتر

محمد التتر، محرر ومشرف GZ تقنية، يعمل على اختبار حلول ووردبريس وإدارة المواقع في بيئات منفصلة قبل توثيق النتائج ونشرها.

مقالات قد تعجبك