🛡 أمان وحماية المواقع

حل مشكلة Not Secure في ووردبريس | إصلاح SSL خطوة بخطوة

Posted by author-avatar
حل مشكلة Not Secure في ووردبريس وإصلاح أخطاء SSL وتفعيل HTTPS

سنتحدث فى هذا المقال عن

حل مشكلة Not Secure في ووردبريس

ظهور رسالة Not Secure في موقع ووردبريس بعد تفعيل شهادة SSL ليس مجرد تنبيه مزعج، بل مؤشر أن المتصفح لا يمنح موقعك “الثقة الكاملة” في الاتصال، وهذا وحده كفيل بتقليل النقرات من نتائج البحث ورفع نسبة الخروج لأن أغلب المستخدمين يتجنبون أي موقع يبدو غير آمن. المشكلة الأصعب أن التحذير قد يستمر رغم أن الموقع يفتح عبر HTTPS، لأن السبب غالبًا لا يكون “غياب الشهادة”، بل خلل في طبقات متعددة تعمل معًا: إعدادات ووردبريس، التحويلات (301 Redirects)، الروابط القديمة داخل قاعدة البيانات، أو تحميل ملفات عبر HTTP داخل صفحة HTTPS (Mixed Content). وقد تظهر المشكلة بأكثر من شكل: قفل مكسور فقط،

أو ERR_TOO_MANY_REDIRECTS، أو توقف wp-admin عن العمل، أو أخطاء متقطعة بسبب Cloudflare أو Proxy. لهذا السبب ستتعامل في هذا الدليل مع المشكلة كمهندس إصلاح لا كشارح نظري: سنبدأ بتشخيص سريع يحدد حالتك بالضبط،

ثم نطبق خطوات مرتبة “بالحرف” لإصلاح الشهادة على السيرفر إن لزم، وضبط عنوان الموقع داخل ووردبريس، وتوحيد نسخة www أو بدونها، وكتابة تحويل واحد صحيح يمنع حلقات التحويل، وتنظيف Mixed Content من الجذر عبر قاعدة البيانات والقالب، ثم ضبط Cloudflare إن كان موجودًا، وفي النهاية اختبار نهائي يؤكد أن التحذير اختفى من كل الصفحات وليس من الصفحة الرئيسية فقط. الهدف أن تنتهي من المقال وأنت قادر على حل المشكلة بنفسك حتى لو واجهتك أي من السيناريوهات الشائعة، بدون حلول مؤقتة أو ترقيع يرجّع المشكلة بعد أسبوع.

قبل أن تبدأ: جهّز 3 أشياء تمنع تضييع الوقت

قبل أي تعديل في SSL أو تحويلات ووردبريس، نفّذ هذه التجهيزات الثلاثة لأن 80% من “فشل الإصلاح” بيكون سببه إنك بتشوف نتيجة قديمة بسبب الكاش أو إنك غيّرت شيء بدون نقطة رجوع. أولًا افتح الموقع من نافذة Incognito/Private وجرب تفتح: الصفحة الرئيسية، صفحة داخلية، و/wp-admin لأن المشاكل أحيانًا تظهر في صفحات معينة فقط. لو التحذير موجود، اعمل لقطة سريعة للحالة الحالية عشان تقارن بعد الإصلاح.

ثانيًا امسح الكاش من إضافة الكاش التي تستخدمها (LiteSpeed/WP Rocket/Autoptimize وغيرها)، وامسح كاش السيرفر من لوحة الاستضافة إن كان متاحًا، ثم امسح كاش المتصفح نفسه، لأن بعض الأدوات تحتفظ بتحويلات 301 قديمة داخل الكاش وتظهر لك وكأن المشكلة مستمرة. ثالثًا خذ نسخة احتياطية سريعة لقاعدة البيانات على الأقل (من أدوات الاستضافة أو إضافة مثل UpdraftPlus) لأننا قد نحتاج لاحقًا لعمل استبدال روابط http إلى https داخل المحتوى، وأي استبدال غير صحيح بدون باك أب قد يسبب مشاكل في الروابط أو الميديا. بعد تنفيذ هذه الثلاث خطوات ستكون جاهزًا لتطبيق الحل بثقة، وستعرف فورًا هل الخطوة نجحت أم أنك ما زلت ترى نسخة مخزنة.

ما معنى رسالة Not Secure في ووردبريس؟

رسالة Not Secure تعني أن المتصفح لا يمنح الاتصال بين الزائر والموقع مستوى الثقة الكامل، أي أن هناك عنصرًا واحدًا على الأقل داخل الصفحة لا يتم تحميله بطريقة مشفّرة. في ووردبريس، هذا التحذير لا يعني بالضرورة أن شهادة SSL غير موجودة أو معطّلة، بل غالبًا يعني أن الشهادة تعمل لكن استخدام HTTPS داخل الموقع غير مكتمل. المتصفح لا ينظر إلى الصفحة ككيان واحد، بل يفحص كل مورد بداخلها: الصور، ملفات CSS، ملفات JavaScript، الخطوط، وحتى طلبات Ajax. إذا وُجد أي ملف يتم تحميله عبر HTTP داخل صفحة HTTPS، يعتبر المتصفح الصفحة “غير آمنة بالكامل” ويعرض التحذير.

في ووردبريس تحديدًا، تظهر هذه المشكلة لأن النظام يعتمد على روابط مخزّنة داخل قاعدة البيانات وروابط يتم توليدها ديناميكيًا حسب الإعدادات. عند الانتقال من HTTP إلى HTTPS بدون تحديث شامل، تبقى روابط قديمة داخل المقالات، الصفحات، أو حتى إعدادات القالب والإضافات. كذلك، إذا كانت إعدادات عنوان الموقع تشير إلى HTTP، سيستمر ووردبريس في توليد روابط غير مشفرة حتى لو كانت الشهادة مفعّلة. هذا التعارض بين البروتوكولين هو السبب الحقيقي وراء ظهور Not Secure في أغلب الحالات.

كيف تعرف عمليًا أن رسالة Not Secure بسبب هذا السبب؟

لتتأكد أن المشكلة ناتجة عن موارد غير مشفرة وليس عن الشهادة نفسها، افتح الصفحة التي يظهر فيها التحذير ثم:

  1. اضغط كليك يمين واختر Inspect

  2. انتقل إلى تبويب Console

  3. ابحث عن رسائل تحتوي على Mixed Content أو روابط تبدأ بـ http://

إذا وجدت أي مورد يتم تحميله عبر HTTP داخل صفحة HTTPS، فهذا يؤكد أن المشكلة ليست في SSL نفسه، بل في طريقة استخدام HTTPS داخل ووردبريس. هذه الخطوة مهمة لأنها توفّر عليك وقتًا كبيرًا وتمنعك من إعادة تفعيل الشهادة أو العبث بالتحويلات دون داعٍ.

لماذا يعتبر المتصفح هذا الأمر خطيرًا؟

المتصفح يتعامل بمنطق صارم: صفحة HTTPS يجب أن تكون مشفّرة بالكامل. وجود مورد واحد غير مشفّر يعني أن الاتصال يمكن التلاعب به جزئيًا، حتى لو كانت بقية الصفحة آمنة. لهذا السبب لا يهتم المتصفح بأن الشهادة “موجودة”، بل يهتم بأن كل ما يُعرض داخل الصفحة آمن. هذا هو السبب الذي يجعل كثيرًا من أصحاب المواقع يظنون أن SSL “لا يعمل”، بينما الحقيقة أن SSL يعمل، لكن الموقع لا يستخدمه بشكل صحيح في كل أجزائه.

ماذا تستنتج من هذه المرحلة قبل الانتقال للحل؟

إذا فهمت هذا القسم جيدًا، ستعرف أن:

  • Not Secure لا تعني دائمًا مشكلة شهادة

  • أغلب الحالات سببها روابط HTTP قديمة أو إعدادات ووردبريس

  • الحل لن يكون بإضافة تحاول “إخفاء التحذير”، بل بتنظيف السبب الحقيقي

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

لماذا تستمر مشكلة SSL بعد تفعيل الشهادة؟

تفعيل شهادة SSL هو “تشغيل الأمان” على السيرفر، لكنه لا يضمن وحده أن ووردبريس سيستخدم HTTPS في كل شيء. السبب أن المشكلة غالبًا ليست في الشهادة، بل في عدم تطابق 4 طبقات تعمل معًا: (1) الشهادة على السيرفر، (2) عنوان الموقع داخل ووردبريس، (3) التحويلات Redirects، (4) الروابط القديمة المخزنة داخل قاعدة البيانات والقالب والإضافات. لو طبقتان فقط اتظبطوا والباقي لا، ستظل ترى Not Secure

أو قفل مكسور أو أخطاء مثل ERR_TOO_MANY_REDIRECTS. مثال شائع: الشهادة سليمة، لكن WordPress Address ما زال HTTP، فيستمر ووردبريس في توليد روابط HTTP داخل صفحات HTTPS. مثال آخر: تحويل HTTPS مضبوط في .htaccess لكن Cloudflare على وضع غير متوافق، فتدخل في حلقة تحويل. لذلك الحل الصحيح ليس “إعادة تثبيت الشهادة”، بل توحيد الطبقات الأربع خطوة بخطوة حتى تصبح كل الروابط والتحويلات والإعدادات متفقة على HTTPS.

كيف تعرف “أي طبقة” هي سبب المشكلة عندك؟ (تشخيص سريع قبل الإصلاح)

ابدأ بهذه الاختبارات السريعة لأنها تحدد السبب في دقيقتين بدل التخمين:

  1. اختبار الشهادة (طبقة السيرفر)
    افتح: https://yourdomain.com
    إذا ظهر تحذير شهادة أو لم يفتح الموقع، فالمشكلة في السيرفر/الشهادة وليست في ووردبريس. هنا توقف وأصلح SSL من الاستضافة.

  2. اختبار عنوان ووردبريس (طبقة WordPress URLs)
    لو الموقع يفتح HTTPS لكن لوحة التحكم تعمل بسلوك غريب أو يعيدك إلى HTTP، فغالبًا WordPress Address/Site Address غير مضبوطين. هذا يظهر عادة كتحويلات غير متوقعة أو تسجيل دخول لا يثبت.

  3. اختبار التحويلات (طبقة Redirects)
    افتح: http://yourdomain.com
    لو يتحول مرة واحدة إلى HTTPS فالوضع غالبًا جيد. لو يحصل تحميل متكرر أو خطأ ERR_TOO_MANY_REDIRECTS، فهناك تضارب تحويلات بين السيرفر/إضافة/Cloudflare.

  4. اختبار Mixed Content (طبقة الروابط داخل المحتوى)
    لو HTTPS شغال لكن القفل مكسور أو Not Secure يظهر في صفحات معينة، افتح Inspect ثم Console وابحث عن Mixed Content أو روابط تبدأ بـ http://. إن ظهرت، فالمشكلة روابط قديمة داخل المحتوى/القالب/إضافة.

الخلاصة العملية لهذا القسم

أنت لا تحتاج “حل واحد”، بل تحتاج أن تجعل كل طبقة تقول نفس الشيء: الموقع HTTPS. لذلك في الخطوات القادمة سنمشي بالتسلسل الصحيح: نثبت الشهادة، نثبت عناوين ووردبريس، نوحد التحويلات بقاعدة واحدة فقط، ثم ننظف الروابط القديمة (Mixed Content) من الجذر، وأخيرًا نضبط Cloudflare/Proxy إن وجد. بهذه الطريقة تختفي المشكلة من كل الصفحات، وليس بشكل جزئي أو مؤقت.

الحالة الأولى: الموقع لا يفتح على HTTPS أو تظهر رسالة “الشهادة غير صالحة”

إذا حاولت فتح الموقع عبر HTTPS وظهر تحذير صريح من المتصفح بأن الشهادة غير صالحة، أو لم يفتح الموقع أصلًا، فهذه مشكلة سيرفر أو شهادة SSL وليست مشكلة ووردبريس. في هذه الحالة لا تحاول تعديل إعدادات ووردبريس أو إضافة تحويلات، لأن النظام ببساطة لا يستقبل اتصالًا آمنًا. السبب غالبًا يكون شهادة غير مفعّلة، منتهية الصلاحية، أو لا تغطي اسم النطاق المستخدم (www أو بدون). الحل هنا يكون حصريًا من لوحة الاستضافة بإعادة تفعيل الشهادة أو إصدارها من جديد.

مؤشر واضح:
المتصفح يمنع الدخول تمامًا أو يعرض تحذيرًا قبل تحميل أي محتوى.

الحالة الثانية: الموقع يفتح عبر HTTPS لكن القفل مكسور أو تظهر Not Secure

إذا كان الموقع يفتح عبر HTTPS بشكل طبيعي، لكن يظهر القفل مكسورًا أو رسالة Not Secure، فهذه ليست مشكلة شهادة. هذه الحالة تشير غالبًا إلى Mixed Content، أي أن الصفحة الآمنة تحتوي على صور أو ملفات أو سكربتات يتم تحميلها عبر HTTP. هذه المشكلة قد تظهر في صفحات معينة فقط، مثل مقالات قديمة أو صفحات تم إنشاؤها قبل تفعيل SSL. هنا الحل لن يكون في إعادة تفعيل الشهادة، بل في تنظيف الروابط القديمة داخل المحتوى وقاعدة البيانات.

مؤشر واضح:
HTTPS يعمل، لكن التحذير يظهر في صفحات محددة وليس في الموقع بالكامل.

الحالة الثالثة: ظهور ERR_TOO_MANY_REDIRECTS أو تحميل الصفحة بلا نهاية

إذا واجهت رسالة ERR_TOO_MANY_REDIRECTS أو لاحظت أن الصفحة تعيد التحميل بشكل متكرر دون فتح، فهذه مشكلة تحويلات متضاربة. غالبًا يكون السبب وجود أكثر من جهة تحاول فرض HTTPS أو توحيد الدومين في نفس الوقت، مثل .htaccess + إضافة Redirect + Cloudflare. النتيجة تكون حلقة تحويل لا نهائية بين HTTP وHTTPS أو بين www وبدونها. في هذه الحالة، أي محاولة لإضافة تحويل جديد بدون إزالة القديم ستزيد المشكلة تعقيدًا.

مؤشر واضح:
الصفحة لا تفتح وتدخل في Loop أو يظهر خطأ Redirect صريح.

الحالة الرابعة: لوحة التحكم لا تفتح بعد تفعيل SSL

إذا كان الموقع نفسه يفتح، لكن /wp-admin لا يعمل أو يعيدك إلى HTTP أو يخرجك من تسجيل الدخول، فالمشكلة غالبًا في عنوان الموقع داخل ووردبريس أو في أن الموقع يعمل خلف Proxy/Cloudflare بدون تعريف صحيح للبروتوكول. ووردبريس هنا لا “يفهم” أن الطلب HTTPS، فيولّد روابط وتحويلات خاطئة. هذه الحالة شائعة جدًا بعد تفعيل SSL مباشرة، والحل يكون بضبط عنوان الموقع أو فرض HTTPS من ملف الإعدادات.

مؤشر واضح:
الموقع يفتح، لكن لوحة التحكم لا تعمل بشكل طبيعي.

ماذا تفعل بعد هذا التشخيص؟

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

أول وأهم خطوة في حل مشكلة Not Secure هي التأكد أن الاتصال الآمن يعمل من الأساس على مستوى السيرفر، لأن أي محاولة لإصلاح المشكلة من داخل ووردبريس قبل نجاح هذه المرحلة تعتبر خطأ شائع يضيّع الوقت وقد يزيد المشكلة تعقيدًا. ووردبريس لا يستطيع “تصحيح” شهادة غير صالحة أو غير مفعّلة، بل يعتمد كليًا على ما يقدّمه السيرفر. لذلك هذه الخطوة ليست اختيارية، بل هي الأساس الذي يُبنى عليه كل ما بعده.

ابدأ بفتح هذا الرابط مباشرة في المتصفح:

https://yourdomain.com

افتحه في نافذة Incognito لتجنب الكاش، ولا تعتمد على التحويل التلقائي من HTTP إلى HTTPS. اكتب الرابط يدويًا. إذا ظهرت صفحة الموقع بشكل طبيعي، بدون أي تحذير أمني أو رسالة منع من المتصفح، فهذا يعني أن السيرفر يقدّم اتصال HTTPS فعليًا، ويمكنك الانتقال للخطوة التالية بثقة. أما إذا ظهرت رسالة مثل “Your connection is not private” أو “Certificate not valid” أو لم يفتح الموقع أصلًا، فتوقف هنا تمامًا، لأن المشكلة ليست في ووردبريس.

ماذا تفعل إذا لم يعمل HTTPS؟

في هذه الحالة يجب الدخول إلى لوحة الاستضافة، وليس إلى ووردبريس. سواء كنت تستخدم cPanel أو Plesk أو أي لوحة أخرى، ابحث عن قسم SSL أو Security ثم تأكد من الآتي:

  • أن شهادة SSL مفعّلة بالفعل على الدومين

  • أن الشهادة غير منتهية الصلاحية

  • أن الشهادة تغطي اسم النطاق الذي تستخدمه فعليًا

هنا يقع خطأ شائع جدًا: كثير من أصحاب المواقع يفعّلون شهادة على
example.com
ثم يفتحون الموقع على
www.example.com

في هذه الحالة سيظهر التحذير لأن الشهادة لا تغطي نسخة www. نفس الشيء يحدث لو العكس صحيح. لذلك يجب التأكد أن الشهادة تغطي النسخة المستخدمة، أو تفعيل شهادة تشمل الاثنين معًا (www وبدون).

نقطة مهمة: لا تختبر من داخل ووردبريس

لا تحاول في هذه المرحلة:

  • تثبيت إضافات SSL

  • تعديل wp-config.php

  • إضافة تحويلات في .htaccess

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

كيف تتأكد 100% أن الشهادة سليمة؟

بعد أن يفتح الموقع على HTTPS بدون تحذير، اضغط على علامة القفل في شريط المتصفح، ثم اختر معلومات الشهادة. يجب أن ترى الآتي:

  • حالة الشهادة: Valid

  • اسم النطاق مطابق تمامًا للرابط المفتوح

  • تاريخ الصلاحية ساري وغير منتهٍ

  • الجهة المصدِرة معروفة (مثل Let’s Encrypt أو جهة موثوقة)

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

متى تنتقل للخطوة التالية؟

انتقل للخطوة الثانية فقط عندما:

  • يفتح الموقع عبر HTTPS بدون تحذير

  • لا يمنعك المتصفح من الدخول

  • تظهر الشهادة كـ Valid

إذا لم تتحقق هذه الشروط، لا تكمل القراءة، لأن أي خطوة لاحقة تعتمد بالكامل على نجاح هذه المرحلة.

الخطوة الثانية: توحيد نسخة الدومين (www أو بدون) قبل أي تحويلات

قبل كتابة أي تحويلات أو تعديل إعدادات ووردبريس، يجب اتخاذ قرار واحد واضح: ما هي النسخة الرسمية للموقع؟
إما:

  • https://www.yourdomain.com
    أو:

  • https://yourdomain.com

وجود النسختين نشطتين في نفس الوقت يعني أن الموقع يُعرض بعنوانين مختلفين، وهو ما يسبب تضاربًا في الروابط، مشاكل في التحويلات، وأحيانًا ظهور أخطاء SSL أو ERR_TOO_MANY_REDIRECTS. المتصفح ومحركات البحث يتعاملان مع www وبدونها كنسختين منفصلتين تمامًا، لذلك عدم توحيدهما من البداية يجعل أي حل لاحق غير مستقر.

كيف تختار النسخة الصحيحة لموقعك؟

الاختيار نفسه ليس “صحيح أو خطأ”، لكن الاستمرارية هي الأهم. لتحديد النسخة الأنسب، راجع الآتي:

  • إذا كان موقعك مسجّلًا في Google Search Console بنسخة معيّنة (www أو بدون)، فالأفضل الالتزام بها.

  • إذا كانت أغلب الروابط الخارجية التي تشير إلى موقعك تستخدم www، فاختيار www يكون أكثر استقرارًا.

  • إذا كنت تستخدم بدون www في الحملات التسويقية أو الطباعة أو الروابط المختصرة، فالتزم بدون www.

المهم هنا: اختيار نسخة واحدة فقط، وليس التبديل بينهما لاحقًا.

ماذا يحدث لو تجاهلت هذه الخطوة؟

تجاهل توحيد النسخة يؤدي إلى:

  • تحويلات متكررة بين www وبدونها

  • توليد روابط داخلية غير متطابقة

  • مشاكل SSL في بعض الصفحات دون غيرها

  • تشتيت محركات البحث بين نسختين من نفس الموقع

ولهذا السبب، توحيد النسخة يأتي قبل أي تحويلات HTTPS أو تنظيف Mixed Content.

ماذا ستفعل عمليًا بعد اختيار النسخة؟

بعد أن تقرر النسخة الرسمية، يجب أن تكون هي نفسها في كل مكان:

  1. داخل ووردبريس
    عنوان الموقع وعنوان ووردبريس يجب أن يكونا بنفس النسخة المختارة.

  2. في التحويلات (Redirects)
    النسخة غير المختارة سيتم تحويلها دائمًا إلى النسخة الرسمية بتحويل 301 واحد فقط.

  3. في Cloudflare (إن وُجد)
    لا تضبط إعدادًا يحوّل إلى نسخة مختلفة عن التي اخترتها.

  4. في الروابط الداخلية
    أي روابط ثابتة أو مذكورة يدويًا يجب أن تستخدم النسخة الرسمية.

مثال عملي لتوضيح الفكرة

إذا قررت أن النسخة الرسمية هي:
https://yourdomain.com

فهذا يعني:

  • https://www.yourdomain.com → يجب أن يتحول دائمًا إلى https://yourdomain.com

  • لا يجب أن يولّد ووردبريس أي رابط يحتوي على www

  • لا يجب أن يقوم Cloudflare أو إضافة ما بإعادة التحويل إلى www مرة أخرى

أي كسر في هذا التسلسل سيؤدي إلى تضارب وتحويلات غير مستقرة.

كيف تعرف أن هذه الخطوة نجحت قبل المتابعة؟

قبل الانتقال للخطوة التالية، اختبر الآتي:

  • افتح النسختين:

    • https://www.yourdomain.com

    • https://yourdomain.com

  • يجب أن تفتح نسخة واحدة فقط مباشرة

  • النسخة الأخرى يجب أن تتحول مرة واحدة فقط إلى النسخة الرسمية

  • لا يوجد إعادة تحميل متكررة أو تغيير في العنوان أكثر من مرة

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

لماذا هذه الخطوة أساسية قبل أي تحويل HTTPS؟

لأنك إذا نفّذت تحويل HTTPS قبل توحيد النسخة، ستجد نفسك أمام سيناريوهات معقدة:

  • HTTP → HTTPS → www → بدون www → HTTPS
    وهنا تبدأ حلقات التحويل والأخطاء.
    لهذا السبب، توحيد النسخة دائمًا يسبق أي تحويلات أخرى.

الخطوة الثالثة: ضبط عنوان الموقع داخل ووردبريس على HTTPS (تطبيق عملي بالحرف)

بعد التأكد أن شهادة SSL تعمل على السيرفر، وبعد توحيد نسخة الدومين (www أو بدون)، تأتي هذه الخطوة كأهم خطوة داخل ووردبريس نفسه. ووردبريس يعتمد على عنوان الموقع اعتمادًا مباشرًا في توليد الروابط الداخلية، تسجيل الدخول، تحميل الملفات، وتنفيذ التحويلات. إذا كان عنوان الموقع مضبوطًا على HTTP بينما الموقع يعمل فعليًا على HTTPS، سيستمر ووردبريس في إنشاء روابط غير مشفرة داخل صفحات مشفرة، مما يؤدي إلى Mixed Content، أو تحويلات غريبة، أو حتى تعطل لوحة التحكم.

الطريقة الأولى: ضبط العنوان من لوحة التحكم (إذا كانت تعمل)

إذا كانت لوحة التحكم تفتح بشكل طبيعي، ادخل إلى الإعدادات → عام، وستجد خيارين أساسيين:

  • WordPress Address (URL)

  • Site Address (URL)

اجعل القيمتين متطابقتين تمامًا وبنفس النسخة التي اخترتها في الخطوة السابقة (www أو بدون) وباستخدام HTTPS، مثل:

https://yourdomain.com

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

مهم جدًا:
لا تضع:

  • واحدة www والثانية بدون

  • واحدة HTTP والأخرى HTTPS

أي اختلاف بسيط هنا سيخلق مشاكل لاحقًا.

متى لا تستخدم لوحة التحكم؟

إذا حدث أحد الأمور التالية:

  • لا تستطيع الدخول إلى /wp-admin

  • الصفحة تعيدك إلى HTTP

  • يظهر ERR_TOO_MANY_REDIRECTS

  • يتم تسجيل خروجك مباشرة بعد تسجيل الدخول

❌ توقف فورًا ولا تحاول تعديل الإعدادات من الداخل، لأن أي حفظ خاطئ قد يقفلك خارج لوحة التحكم بالكامل.

الطريقة الثانية (الآمنة): فرض العنوان من ملف wp-config.php

في الحالات السابقة، الحل الصحيح هو تجاوز قاعدة البيانات بالكامل وفرض عنوان الموقع يدويًا من ملف الإعدادات. هذه الطريقة هي الأكثر أمانًا عند وجود تحويلات أو مشاكل SSL، لأنها تُجبر ووردبريس على استخدام HTTPS مهما كانت القيم المخزنة في الإعدادات.

افتح ملف wp-config.php من مدير الملفات أو عبر FTP، وأضف السطرين التاليين قبل سطر:

/* That's all, stop editing! */

ضع:

define('WP_HOME','https://yourdomain.com');
define('WP_SITEURL','https://yourdomain.com');

احرص أن تستخدم نفس النسخة الموحدة (www أو بدون) التي قررتها سابقًا.

لماذا هذه الطريقة فعّالة؟

  • تتجاوز إعدادات قاعدة البيانات

  • تمنع ووردبريس من توليد روابط HTTP

  • تحل مشاكل الدخول والتحويل في أغلب حالات SSL

  • لا تعتمد على إضافات أو كاش

لهذا السبب تُستخدم هذه الطريقة كثيرًا في الإصلاحات الاحترافية عندما تكون لوحة التحكم غير مستقرة.

ماذا تفعل بعد إضافة السطرين؟

بعد حفظ الملف:

  1. افتح /wp-admin

  2. سجّل الدخول وتأكد أن الجلسة ثابتة ولا يتم تسجيل خروجك

  3. افتح صفحة داخلية أو مقال قديم

  4. راقب شريط العنوان وتأكد أن كل الروابط تبدأ بـ HTTPS

لا تقلق إذا وجدت أن إعدادات العنوان في لوحة التحكم أصبحت غير قابلة للتعديل، فهذا طبيعي عند فرض القيم من wp-config.php.

كيف تتأكد أن الخطوة نجحت بنسبة 100%؟

اعتبر الخطوة ناجحة فقط إذا تحققت الشروط التالية:

  • /wp-admin يعمل بدون تحويلات غريبة

  • الصفحة الرئيسية والصفحات الداخلية تفتح على HTTPS

  • لا يتم الرجوع إلى HTTP بعد تسجيل الدخول

  • لا يظهر تحذير SSL بسبب روابط يولدها ووردبريس نفسه

إذا تحققت هذه النقاط، فهذا يعني أن ووردبريس أصبح “فاهم” أن الموقع يعمل على HTTPS، ويمكنك الانتقال بأمان للخطوة التالية.

خطأ شائع يجب تجنبه هنا

لا تستخدم إضافات “Force SSL” أو “Fix HTTPS” في هذه المرحلة، لأن هذه الإضافات قد تخفي المشكلة مؤقتًا بينما يظل عنوان الموقع نفسه خاطئًا. الحل الصحيح هو تصحيح المصدر، وليس إجبار المتصفح على تجاهل الخطأ.

الخطوة الرابعة: تنفيذ تحويل 301 واحد صحيح من HTTP إلى HTTPS (بدون تضارب)

بعد التأكد من أن الشهادة تعمل، وتوحيد نسخة الدومين، وضبط عنوان الموقع داخل ووردبريس على HTTPS، تأتي مرحلة تنفيذ التحويل النهائي من HTTP إلى HTTPS. هذه الخطوة هدفها بسيط جدًا لكنه حساس: أي زيارة عبر HTTP يجب أن تتحول مرة واحدة فقط إلى النسخة الآمنة من الموقع، بدون حلقات تحويل، وبدون تعارض مع ووردبريس أو Cloudflare أو الكاش. الخطأ الشائع هنا هو استخدام أكثر من أداة في نفس الوقت: إضافة تحويل + htaccess + إعدادات استضافة، وهو ما يؤدي غالبًا إلى ERR_TOO_MANY_REDIRECTS أو سلوك غير مستقر.

لماذا يجب أن يكون التحويل على مستوى السيرفر؟

التحويل على مستوى السيرفر (Apache أو Nginx) يتم قبل تحميل ووردبريس أو الإضافات أو الكاش، لذلك:

  • أسرع في التنفيذ

  • لا يتأثر بالكاش

  • لا يتعارض مع إضافات

  • أوضح لمحركات البحث

أما الإضافات، فهي تعمل بعد تحميل ووردبريس، وقد:

  • تُخزَّن في الكاش

  • تتعارض مع Cloudflare

  • تُكرر التحويل أكثر من مرة

لذلك في إصلاح SSL الاحترافي: التحويل يتم من السيرفر فقط.

سيناريو Apache: أين تضع التحويل؟

إذا كان موقعك يعمل على Apache (وهو الأكثر شيوعًا)، افتح ملف .htaccess الموجود في جذر ووردبريس (نفس مكان wp-config.php).
ضع كود التحويل أعلى أي كود آخر، وقبل أسطر ووردبريس الافتراضية.

التحويل الأساسي: HTTP → HTTPS فقط

ابدأ دائمًا بالتحويل الأبسط، وهو تحويل HTTP إلى HTTPS بدون التعامل مع www:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

هذا الكود يقول:
أي طلب ليس HTTPS → حوّله إلى HTTPS بنفس الدومين والمسار.

❗ لا تضف أي كود آخر في نفس الوقت قبل اختبار هذا التحويل.

ماذا لو كنت تريد توحيد www أو بدونها؟

بعد أن قررت في الخطوة الثانية النسخة الرسمية (www أو بدون)، يمكنك دمج توحيد النسخة مع HTTPS في قاعدة واحدة فقط.

مثال: توحيد بدون www + HTTPS

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

مثال: توحيد www + HTTPS

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

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

أخطاء قاتلة يجب تجنبها هنا

  • ❌ وضع تحويل HTTP → HTTPS في htaccess، وتحويل آخر داخل إضافة

  • ❌ استخدام أكثر من RewriteEngine On في أماكن مختلفة

  • ❌ كتابة تحويل www في كود، وCloudflare يحوّل إلى النسخة العكسية

  • ❌ اختبار التحويل بدون مسح الكاش

أي خطأ من دول كفيل بعمل حلقة تحويل لا نهائية.

كيف تختبر التحويل بشكل صحيح (الاختبار الحقيقي)

بعد حفظ .htaccess:

  1. افتح نافذة Incognito

  2. افتح رابطًا مباشرًا:

    http://yourdomain.com/page

  3. راقب شريط العنوان

النتيجة الصحيحة:

  • يتحول الرابط مرة واحدة فقط

  • ينتهي على:

    https://yourdomain.com/page

  • لا يوجد وميض أو إعادة تحميل متكررة

  • لا تظهر رسالة ERR_TOO_MANY_REDIRECTS

لو لاحظت أكثر من تحويل أو توقف الصفحة، فهناك تضارب يجب حله قبل المتابعة.

ماذا تفعل إذا ظهر ERR_TOO_MANY_REDIRECTS بعد هذه الخطوة؟

توقف فورًا ولا تضف أي كود جديد. افعل التالي:

  • عطّل أي إضافة Redirect أو SSL

  • امسح كاش المتصفح

  • لو تستخدم Cloudflare، عطّله مؤقتًا أو اضبطه على Full (Strict)

  • تأكد أن عنوان ووردبريس في الخطوة الثالثة مطابق تمامًا للنسخة النهائية

بعدها أعد الاختبار.

متى تعتبر هذه الخطوة ناجحة؟

اعتبر تحويل HTTPS مضبوطًا بشكل صحيح فقط إذا:

  • أي رابط HTTP يتحول مرة واحدة إلى HTTPS

  • لا توجد حلقات تحويل

  • الموقع والصفحات الداخلية وwp-admin تعمل بدون أخطاء

  • لا تحتاج لأي إضافة لفرض HTTPS

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

الخطوة الخامسة: حل مشكلة ERR_TOO_MANY_REDIRECTS بطريقة عملية ومنهجية

ظهور خطأ ERR_TOO_MANY_REDIRECTS يعني ببساطة أن هناك أكثر من جهة تحاول فرض تحويلات في نفس الوقت، لكن كل جهة تطلب اتجاهًا مختلفًا. المتصفح يدخل في حلقة لا نهائية بين HTTP وHTTPS أو بين www وبدونها، فيتوقف عن المحاولة ويعرض الخطأ. المهم هنا أن تفهم أن المشكلة ليست في كود واحد بعينه، بل في تضارب بين أكثر من طبقة. لذلك الحل لا يكون بإضافة تحويل جديد، بل بإزالة التحويلات الزائدة واحدة تلو الأخرى حتى يتبقى مصدر واحد فقط للتحويل.

القاعدة الذهبية قبل البدء

في أي حالة ERR_TOO_MANY_REDIRECTS:

  • ❌ لا تضف كود جديد

  • ❌ لا تثبّت إضافة جديدة

  • ❌ لا تغيّر كل شيء دفعة واحدة

الحل الصحيح هو التبسيط، وليس التعقيد.

الخطوة 5.1: امسح أثر الماضي قبل الحكم على أي نتيجة

ابدأ دائمًا بمسح كاش المتصفح وافتح الموقع في نافذة Incognito/Private. السبب أن المتصفح قد يكون مخزن تحويلات 301 قديمة، فيُظهر لك الخطأ حتى بعد إصلاحه فعليًا. لا تعتمد على نافذة عادية أبدًا أثناء الاختبار. افتح الصفحة الرئيسية ورابطًا داخليًا عبر HTTP لتتأكد أن السلوك الحالي هو الحقيقي وليس نتيجة كاش.

الخطوة 5.2: عطّل أي إضافة تقوم بفرض HTTPS أو Redirect

ادخل إلى لوحة التحكم (إن أمكن) أو إلى مجلد الإضافات، وعطّل مؤقتًا:

  • أي إضافة SSL

  • أي إضافة Redirect

  • أي إضافة “Force HTTPS”

السبب أن هذه الإضافات تعمل بعد تحميل ووردبريس، بينما التحويل الذي نفّذته في .htaccess يعمل قبل ذلك. وجود الاثنين معًا يعني تحويلين لنفس الطلب، وغالبًا باتجاهين مختلفين. لا تقلق، هذا التعطيل مؤقت فقط للتشخيص.

الخطوة 5.3: راجع ملف .htaccess وتأكد من وجود تحويل واحد فقط

افتح ملف .htaccess وتحقق من الآتي بدقة:

  • يوجد RewriteEngine On مرة واحدة فقط

  • يوجد قاعدة تحويل واحدة فقط خاصة بـ HTTPS / www

  • لا توجد أكواد مكررة أو قديمة معلّق عليها بتعليقات

إذا وجدت أكثر من قاعدة تحويل تحاول:

  • HTTP → HTTPS

  • www → بدون

  • بدون → www

في أماكن مختلفة، فهذه وصفة جاهزة لـ Redirect Loop.
احتفظ بقاعدة واحدة فقط، واحذف أو علّق أي كود آخر مؤقتًا.

الخطوة 5.4: راجع إعدادات Cloudflare (إن كنت تستخدمه)

Cloudflare هو أكثر سبب شائع لاستمرار ERR_TOO_MANY_REDIRECTS بعد كل شيء “يبدو” صحيحًا. ادخل إلى إعدادات SSL في Cloudflare وتحقق مما يلي:

  • اجعل SSL Mode = Full (Strict) إذا كانت شهادة السيرفر سليمة

  • ❌ تجنب Flexible تمامًا، لأنه:

    • يجعل المتصفح HTTPS

    • والسيرفر HTTP

    • فيدخل الموقع في حلقة تحويل مستمرة

كذلك تأكد أن:

  • Cloudflare لا يفرض Redirect إلى www بينما .htaccess يحوّل إلى بدون www (أو العكس)

لو شككت أن Cloudflare هو السبب، عطّله مؤقتًا واختبر الموقع مباشرة من السيرفر. لو فتح بدون خطأ، فالمشكلة مؤكدة من إعدادات Cloudflare.

الخطوة 5.5: راجع عنوان الموقع داخل ووردبريس مرة أخيرة

ارجع للخطوة الثالثة وتأكد أن:

  • WP_HOME

  • WP_SITEURL

مضبوطين على نفس النسخة النهائية (www أو بدون) وبـ HTTPS.
أي اختلاف بسيط هنا قد يعيد حلقة التحويل حتى لو كان .htaccess صحيحًا.

كيف تختبر بعد كل تعديل (الاختبار الصحيح)

بعد كل خطوة:

  1. امسح كاش المتصفح

  2. افتح نافذة Incognito

  3. افتح:

    http://yourdomain.com/page

النتيجة الصحيحة:

  • تحويل واحد فقط

  • الوصول إلى:

    https://yourdomain.com/page

  • الصفحة تفتح فورًا بدون رسالة خطأ

إذا اختفى الخطأ بعد خطوة معينة، توقف — لا تكمل حذف أو تعديل أشياء أخرى.

متى تعتبر مشكلة ERR_TOO_MANY_REDIRECTS محلولة نهائيًا؟

اعتبر المشكلة منتهية فقط إذا:

  • الموقع يفتح فورًا بدون Loop

  • الصفحة الرئيسية والصفحات الداخلية تعمل

  • /wp-admin يعمل بدون إعادة توجيه

  • HTTP يتحول مرة واحدة فقط إلى HTTPS

في هذه المرحلة، التحويلات أصبحت مستقرة، ويمكنك الانتقال للخطوة التالية بأمان.

الخطوة السادسة: إصلاح Mixed Content (القفل مكسور رغم أن HTTPS يعمل)

إذا كان موقعك يفتح عبر HTTPS بدون أخطاء شهادة، لكن القفل في المتصفح مكسور أو تظهر عبارة Not Secure في صفحات معيّنة، فهذه ليست مشكلة SSL ولا تحويلات، بل مشكلة Mixed Content. معناها ببساطة أن الصفحة نفسها تُحمّل عبر HTTPS، لكن بداخلها عناصر (صور، ملفات CSS، JavaScript، خطوط، أو حتى طلبات Ajax) يتم تحميلها عبر HTTP. المتصفح هنا يتعامل بصرامة: صفحة آمنة يجب أن تكون مشفّرة بالكامل، ووجود مورد واحد غير مشفّر يكفي لكسر الثقة وعرض التحذير، حتى لو كانت الشهادة سليمة وكل التحويلات صحيحة.

لماذا تظهر مشكلة Mixed Content في ووردبريس تحديدًا؟

ووردبريس لا يغيّر الروابط القديمة تلقائيًا عند تفعيل SSL. النظام يخزّن روابط:

  • الصور داخل المقالات

  • روابط الميديا

  • روابط داخل الصفحات

  • إعدادات بعض القوالب والإضافات

داخل قاعدة البيانات كنصوص صريحة. إذا تم إنشاء هذه المحتويات قبل تفعيل SSL، فغالبًا تكون مكتوبة بـ http://. بعد تفعيل HTTPS، تستمر هذه الروابط في الظهور داخل صفحات آمنة، فيعتبر المتصفح أن الاتصال “غير آمن بالكامل”. لذلك أي حل يعتمد على “Force HTTPS” فقط دون تنظيف قاعدة البيانات هو حل شكلي قد يخفي المشكلة مؤقتًا لكنه لا يعالج السبب.

كيف تتأكد أن المشكلة فعلًا Mixed Content قبل الإصلاح؟

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

  1. اضغط F12 أو كليك يمين → Inspect

  2. انتقل إلى تبويب Console

  3. ابحث عن رسائل تحتوي على:

    • Mixed Content

    • أو روابط تبدأ بـ http://

إذا وجدت طلبات HTTP داخل صفحة HTTPS، فهذا تأكيد قاطع أن المشكلة Mixed Content، ولا علاقة لها بالشهادة أو التحويلات.

الحل الصحيح: تنظيف الروابط من قاعدة البيانات (الطريقة العملية الأسرع)

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

الخطوة العملية باستخدام Better Search Replace

  1. ثبّت إضافة Better Search Replace

  2. ادخل إلى صفحة الإضافة

  3. في خانة Search for اكتب:

    https://mustafa-wp.com

  4. في خانة Replace with اكتب:

    https://mustafa-wp.com

  5. اختر الجداول (يمكن اختيار كل الجداول في أغلب الحالات)

  6. فعّل خيار Dry Run أولًا وشغّل العملية

  7. راجع النتائج، ثم ألغِ Dry Run ونفّذ الاستبدال الحقيقي

هذا الإجراء سيقوم بـ:

  • تحديث روابط الصور داخل المقالات

  • إصلاح روابط الميديا القديمة

  • تنظيف روابط الصفحات والنصوص المخزّنة

  • تقليل ظهور Mixed Content بشكل جذري

متى لا يكفي الاستبدال داخل قاعدة البيانات؟

في بعض الحالات، قد يستمر Mixed Content حتى بعد تنظيف قاعدة البيانات، والسبب يكون:

  • رابط HTTP مكتوب ثابتًا داخل ملف قالب

  • ملف CSS يحتوي على رابط صورة HTTP

  • إضافة قديمة تستدعي ملفات عبر HTTP

في هذه الحالة:

  • افتح Console وانسخ رابط HTTP الظاهر

  • حدّد مصدره (قالب / إضافة)

  • عدّل المصدر ليستخدم HTTPS أو رابط نسبي (relative URL)

هذه الحالات أقل شيوعًا، لكنها موجودة خصوصًا في القوالب القديمة أو المعدّلة يدويًا.

خطأ شائع يجب تجنبه هنا

❌ الاعتماد فقط على إضافة “Force HTTPS”
❌ تجاهل Mixed Content لأن “الموقع يفتح”
❌ عدم عمل Backup قبل الاستبدال

هذه الأخطاء تؤدي إلى عودة Not Secure لاحقًا أو إلى مشاكل ميديا غير متوقعة.

كيف تتأكد أن Mixed Content اختفى نهائيًا؟

بعد تنفيذ الاستبدال:

  1. امسح كاش الإضافة

  2. امسح كاش السيرفر

  3. افتح الصفحة في نافذة Incognito

  4. اضغط F12 → Console

النتيجة الصحيحة:

  • لا توجد أي طلبات تبدأ بـ http://

  • لا توجد رسائل Mixed Content

  • القفل يظهر بشكل طبيعي بدون تحذير

إذا تحققت هذه النقاط، فهذا يعني أن آخر سبب حقيقي لظهور Not Secure قد اختفى.

ماذا بعد هذه الخطوة؟

بعد إصلاح Mixed Content:

  • البروتوكول مستقر

  • التحويلات سليمة

  • الروابط نظيفة

إذا كنت تستخدم Cloudflare أو Proxy، ننتقل للخطوة الأخيرة لضبطه بشكل يمنع أي تضارب مستقبلي.

الخطوة السابعة: إذا كان لديك Cloudflare أو Proxy (تطبيق يمنع تضارب HTTPS نهائيًا)

عند استخدام Cloudflare أو أي Proxy/Load Balancer، يحدث سيناريو شائع يفسّر لماذا يستمر Not Secure أو تظهر تحويلات غريبة رغم أن كل شيء يبدو صحيحًا: المتصفح يرى الموقع HTTPS، لكن السيرفر يستقبل الطلب داخليًا HTTP لأن Cloudflare هو من يتولى التشفير عند الحافة (Edge). في هذه الحالة، ووردبريس قد “يصدق” ما يراه من السيرفر (HTTP) ويبدأ في توليد روابط HTTP أو يطبق تحويلات غير صحيحة، فتظهر لديك مشاكل مثل روابط مختلطة، أو تسجيل دخول لا يثبت، أو Redirect Loop. الهدف هنا ليس فقط ضبط Cloudflare، بل جعل ووردبريس يفهم البروتوكول الحقيقي للزائر حتى لا يعود الخطأ لاحقًا.

أولًا: اضبط Cloudflare بالطريقة الصحيحة (الجزء الذي يمنع أغلب المشاكل)

ادخل إلى Cloudflare → SSL/TLS ثم اختر وضع SSL الصحيح:

  • Full (Strict) هو الخيار الأفضل إذا كانت شهادة السيرفر سليمة (Let’s Encrypt أو شهادة موثوقة).

  • تجنب Flexible تمامًا لأنه يسبب حلقات تحويل في أغلب المواقع، لأنه يجعل المتصفح HTTPS بينما Cloudflare يتواصل مع السيرفر HTTP، ثم السيرفر يحاول تحويل HTTP إلى HTTPS فتبدأ الحلقة.

بعد اختيار Full (Strict)، تأكد أن الشهادة على السيرفر فعّالة فعلًا (الخطوة 1). لو كانت الشهادة على السيرفر غير صالحة، Full (Strict) قد يمنع التحميل. لذلك هذا الضبط لا يتم إلا بعد نجاح اختبار HTTPS على السيرفر.

كيف تتأكد أن الإعداد صحيح؟
بعد التغيير، افتح موقعك من نافذة Incognito وجرّب: الصفحة الرئيسية + صفحة داخلية + /wp-admin. إذا اختفت التحويلات الغريبة واستقرت الروابط، فأنت على الإعداد الصحيح.

ثانيًا: اجعل ووردبريس يتعرف أن الطلب HTTPS خلف Cloudflare (التطبيق داخل wp-config.php)

حتى مع ضبط Cloudflare بشكل صحيح، قد تحتاج إلى خطوة صغيرة داخل ووردبريس لضمان أنه يتعامل مع الطلب كـ HTTPS عندما يصل عبر Proxy. السبب أن ووردبريس يبني الكثير من الروابط اعتمادًا على قيمة $_SERVER['HTTPS']. في بعض البيئات، هذه القيمة لا تكون “on” لأن الطلب الداخلي من Cloudflare إلى السيرفر قد يبدو HTTP. الحل هنا هو قراءة ترويسة Cloudflare/Proxy التي تؤكد البروتوكول الحقيقي، ثم إجبار ووردبريس على اعتبار الاتصال HTTPS.

افتح ملف wp-config.php وضع هذا الكود قبل سطر “stop editing”:

if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}

هذا الكود يقول: إذا وصل ترويسة تؤكد أن بروتوكول الزائر HTTPS، اجعل ووردبريس يعتبر الاتصال HTTPS حتى لو السيرفر داخليًا يرى غير ذلك.

متى تحتاج هذا الكود؟
إذا لاحظت واحدًا من الآتي:

  • ووردبريس يولّد روابط HTTP رغم أن الموقع HTTPS

  • يحدث تسجيل خروج بعد تسجيل الدخول

  • بعض الصفحات تعمل وبعضها يعطي Not Secure

  • تحصل تحويلات غريبة بعد تفعيل Cloudflare

ثالثًا: تجنب التعارض بين “توثيق الدومين” وCloudflare

Cloudflare لديه خيار شائع قد يسبب تضارب إذا كنت بالفعل تملك تحويلات في .htaccess:

  • Always Use HTTPS

  • و Automatic HTTPS Rewrites

  • و Page Rules Redirects

لو أنت بالفعل طبقت تحويل 301 على السيرفر (الخطوة 4)، فالأفضل:

  • ألا تجعل Cloudflare ينفذ تحويل HTTPS إضافي بنفسه
    لأنك بذلك تخلق “طرف ثاني” في التحويلات وقد تعود مشكلة ERR_TOO_MANY_REDIRECTS.

القاعدة الذهبية:
اجعل التحويل على السيرفر فقط، واجعل Cloudflare “يمرر” الاتصالات بشكل صحيح، لا أن يعيد توجيهها بطريقته أيضًا (إلا إذا كنت تعتمد عليه بدل السيرفر بالكامل، وهذا سيناريو مختلف).

كيف تختبر أن Cloudflare/Proxy أصبح متوافقًا مع HTTPS؟

بعد ضبط Cloudflare وإضافة كود wp-config إن لزم، نفّذ اختبارًا عمليًا واضحًا:

  1. افتح:

http://yourdomain.com/page

يجب أن يتحول مرة واحدة فقط إلى:

https://yourdomain.com/page

  1. افتح صفحة داخلية قديمة كانت تعاني Mixed Content، وتأكد أن القفل طبيعي.

  2. افتح /wp-admin وسجّل الدخول وتأكد أن الجلسة ثابتة ولا يحدث Logout.

إذا نجحت الاختبارات الثلاثة، فهذا يعني أن Cloudflare/Proxy لم يعد يسبب تضاربًا، وأن ووردبريس يفهم البروتوكول الصحيح.

ماذا لو ظهرت 525/526 أو SSL Handshake بعد Full (Strict)؟

أحيانًا يظهر خطأ 525/526 عند Cloudflare بعد اختيار Full (Strict). هذا عادة يعني أن Cloudflare لا يستطيع التحقق من شهادة السيرفر أو الاتصال به بشكل صحيح. الحل هنا ليس العودة إلى Flexible، بل إصلاح شهادة السيرفر نفسها أو التأكد من تفعيلها على الدومين الصحيح. الهدف أن يكون السيرفر نفسه قادرًا على تقديم HTTPS موثوق، ثم Cloudflare يعمل كطبقة إضافية، لا كبديل عن أمان السيرفر.

الخطوة الثامنة: مسح الكاش واختبار نهائي يثبت أن مشكلة SSL انتهت تمامًا

بعد تنفيذ جميع خطوات الإصلاح السابقة، لا تفترض أبدًا أن المشكلة انتهت لمجرد أن الصفحة الرئيسية فتحت بدون تحذير. أخطاء SSL وNot Secure من أكثر المشاكل التي تختفي ظاهريًا بسبب الكاش ثم تعود للظهور لاحقًا، أو تظهر في صفحات معينة فقط. لذلك هذه الخطوة ليست مجرد إجراء روتيني، بل اختبار نهائي منظم يؤكد أن الإصلاح تم من الجذر وليس بالصدفة.

ابدأ بمسح الكاش بالترتيب الصحيح. أولًا امسح كاش إضافة الكاش داخل ووردبريس (سواء LiteSpeed، WP Rocket، W3 Total Cache، أو غيرها)، لأن هذه الإضافات قد تحتفظ بنسخ قديمة من الصفحات بروابط HTTP. ثانيًا، إن كانت الاستضافة توفر كاش سيرفر (مثل Varnish أو Nginx Cache)، امسحه من لوحة الاستضافة. ثالثًا، إذا كنت تستخدم Cloudflare، نفّذ Purge Cache (مسح كامل)، لأن Cloudflare قد يعرض نسخة قديمة من الصفحة حتى لو السيرفر نفسه تم إصلاحه. أخيرًا، افتح الموقع في نافذة Incognito/Private لتتأكد أنك ترى النسخة الحقيقية الحالية بدون أي أثر للكوكيز أو التحويلات المخزنة.

الاختبار النهائي الصحيح (لا تختبر صفحة واحدة فقط)

بعد مسح الكاش، نفّذ اختبارًا عمليًا على أكثر من نوع صفحة، لأن بعض المشاكل لا تظهر إلا خارج الصفحة الرئيسية:

  1. الصفحة الرئيسية
    تأكد أن الرابط يبدأ بـ HTTPS، وأن القفل في المتصفح طبيعي بدون تحذير.

  2. صفحة داخلية أو مقال قديم
    هذه الصفحات غالبًا ما تحتوي روابط قديمة أو صور تم رفعها قبل تفعيل SSL، وهي أول مكان يظهر فيه Mixed Content لو ما زال موجودًا.

  3. صفحة منتج أو خدمة (إن وُجدت)
    صفحات المنتجات أو الخدمات قد تستخدم قوالب مختلفة أو سكربتات إضافية، لذلك اختبارها مهم للتأكد أن القالب بالكامل متوافق مع HTTPS.

  4. لوحة التحكم /wp-admin
    افتحها وسجّل الدخول وتأكد أن الجلسة ثابتة، ولا يحدث تسجيل خروج مفاجئ أو تحويل إلى HTTP.

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

اختبار التحويل النهائي من HTTP إلى HTTPS

بعد ذلك، اختبر التحويل نفسه وليس فقط HTTPS:

  • افتح:

    http://yourdomain.com

  • ثم:

    http://yourdomain.com/page

النتيجة الصحيحة:

  • التحويل يتم مرة واحدة فقط

  • ينتهي دائمًا على:

    https://yourdomain.com

  • لا توجد إعادة تحميل متكررة

  • لا يظهر ERR_TOO_MANY_REDIRECTS

هذا الاختبار يؤكد أن التحويل 301 مستقر ولا يوجد طرف آخر يحاول فرض تحويل إضافي.

ماذا لو بقي تحذير في صفحة واحدة فقط؟

إذا لاحظت أن:

  • الصفحة الرئيسية سليمة

  • أغلب الصفحات سليمة

  • لكن صفحة واحدة فقط ما زالت تظهر Not Secure

فهذا غالبًا يعني وجود مورد HTTP ثابت داخل هذه الصفحة، مثل:

  • صورة مضافة يدويًا برابط HTTP

  • كود مضمّن داخل المحتوى

  • سكربت من إضافة معينة

في هذه الحالة:

  1. افتح الصفحة واضغط F12 → Console

  2. ابحث عن أي رابط يبدأ بـ http://

  3. حدّد مصدره (قالب – إضافة – محتوى الصفحة)

  4. عدّل المصدر ليستخدم HTTPS أو رابط نسبي

لا تعد تشغيل كل خطوات SSL من البداية، لأن المشكلة هنا محلية وليست عامة.

متى تعتبر المشكلة انتهت 100%؟

اعتبر أن مشكلة SSL انتهت نهائيًا فقط عندما:

  • كل الصفحات تفتح عبر HTTPS بدون تحذير

  • القفل يظهر طبيعي في المتصفح

  • لا توجد رسائل Mixed Content في Console

  • HTTP يتحول مرة واحدة فقط إلى HTTPS

  • /wp-admin يعمل بدون مشاكل

  • لا تحتاج لأي إضافة “Force HTTPS”

عند هذه النقطة، أنت لم تُخفِ التحذير، بل أصلحت السبب الحقيقي، ولن تعود المشكلة بعد تحديث قالب أو إضافة أو تفريغ كاش.

ملاحظة أخيرة مهمة

إذا ظهرت مشكلة جديدة بعد أيام أو أسابيع، فهي غالبًا بسبب:

  • إضافة جديدة تضيف مورد HTTP

  • تعديل في القالب

  • استيراد محتوى قديم يحتوي روابط HTTP

والحل دائمًا يكون بنفس المنهج: تحديد الصفحة → فحص Console → إصلاح المصدر، وليس إعادة كل الخطوات من البداية.

متى تعتبر مشكلة SSL في ووردبريس محلولة تمامًا؟

تُعتبر مشكلة SSL في ووردبريس محلولة نهائيًا فنيًا وليس شكليًا فقط عندما تتطابق كل طبقات الموقع على استخدام HTTPS بدون أي استثناء. الحل الحقيقي لا يعني أن التحذير اختفى من الصفحة الرئيسية فقط، بل يعني أن كل مسار داخل الموقع — من الصفحات العامة إلى لوحة التحكم — يعمل عبر اتصال آمن ومستقر، بدون تحويلات متكررة أو موارد غير مشفرة. في هذه المرحلة، المتصفح لم يعد يرى أي عنصر يمكن أن يضعف الثقة، وووردبريس نفسه أصبح يولّد روابط صحيحة دون تدخل إضافات أو حلول مؤقتة.

المعيار الأول: كل الصفحات تعمل عبر HTTPS بدون أي تحذير

افتح الصفحة الرئيسية، ثم صفحات داخلية، ثم صفحات تم إنشاؤها قديمًا، وتأكد أن:

  • الرابط يبدأ بـ https://

  • لا يظهر تحذير Not Secure

  • القفل في شريط المتصفح طبيعي بدون تنبيه

هذا يؤكد أن HTTPS ليس مقتصرًا على الصفحة الرئيسية فقط، بل مطبق على مستوى الموقع بالكامل.

المعيار الثاني: لا توجد أي طلبات HTTP داخل صفحات HTTPS

حتى لو اختفى التحذير بصريًا، لا تعتبر المشكلة منتهية قبل فحص المصدر. افتح أي صفحة واضغط:

  • F12 → Console

  • أو Network → Filter: http

إذا لم تظهر أي طلبات تبدأ بـ http:// داخل صفحة https://، فهذا يعني أن:

  • Mixed Content تم تنظيفه من الجذر

  • لا توجد صور أو سكربتات أو ملفات قديمة غير مشفرة

  • القالب والإضافات متوافقة مع HTTPS

هذا المعيار مهم لأنه يمنع عودة المشكلة لاحقًا بعد مسح الكاش أو تحديث المتصفح.

المعيار الثالث: التحويل من HTTP إلى HTTPS يتم مرة واحدة فقط

اختبر التحويل يدويًا بفتح:

http://yourdomain.com
http://yourdomain.com/page

النتيجة الصحيحة:

  • تحويل واحد فقط

  • الوصول مباشرة إلى النسخة النهائية:

    https://yourdomain.com

  • لا يوجد وميض أو إعادة تحميل متكررة

  • لا تظهر رسالة ERR_TOO_MANY_REDIRECTS

هذا يؤكد أن التحويل 301 مستقر، ولا توجد جهة ثانية (إضافة، Cloudflare، كاش) تحاول فرض تحويل إضافي.

المعيار الرابع: لوحة التحكم تعمل بدون مشاكل

افتح /wp-admin وسجّل الدخول، وتأكد من الآتي:

  • لا يتم تحويلك إلى HTTP

  • لا يحدث تسجيل خروج مفاجئ

  • لا تظهر إعادة توجيه غريبة بعد تسجيل الدخول

  • لوحة التحكم تعمل بنفس استقرار الصفحات العامة

مشاكل SSL كثيرًا ما تظهر في لوحة التحكم حتى لو الواجهة العامة تبدو سليمة، لذلك هذا الاختبار لا يقل أهمية عن باقي المعايير.

المعيار الخامس: الموقع لا يعتمد على حلول قسرية أو مؤقتة

إذا كان الموقع:

  • يعمل بدون إضافة “Force HTTPS”

  • لا يعتمد على JavaScript لتغيير البروتوكول

  • لا يحتاج إلى إعادة توجيه من Cloudflare فوق تحويل السيرفر

فهذا يعني أن المصدر نفسه سليم، وأن HTTPS جزء طبيعي من بنية الموقع، وليس طبقة مفروضة فوق مشكلة مخفية.

ماذا يعني تحقيق هذه المعايير عمليًا؟

عند تحقق هذه النقاط، فأنت:

  • لم تُخفِ تحذير Not Secure

  • لم تعتمد على كاش أو إضافة

  • لم تعالج العرض وتترك السبب

بل قمت بـ:

  • توحيد البروتوكول

  • توحيد التحويلات

  • تنظيف الروابط القديمة

  • ضبط ووردبريس ليعمل بشكل صحيح خلف HTTPS

وهذا هو النوع من الحلول التي لا تنهار بعد:

  • تحديث قالب

  • تثبيت إضافة جديدة

  • تفريغ كاش

  • تغيير إعدادات Cloudflare

الخلاصة الفنية لهذا القسم

مشكلة SSL في ووردبريس تُعتبر محلولة نهائيًا عندما يصبح HTTPS هو “الوضع الطبيعي” للموقع، وليس استثناءً أو نتيجة تحويل قسري. في هذه المرحلة، يكون المتصفح، ووردبريس، السيرفر، وأي Proxy أو CDN متفقين على بروتوكول واحد بدون تعارض. عندها فقط يمكنك الاطمئنان أن رسالة Not Secure لن تعود، وأن موقعك آمن ومستقر على المدى الطويل.

في النهاية,,,,,,

حل مشكلة SSL في ووردبريس لا يتم بإضافة واحدة ولا بزر “تفعيل HTTPS”، بل بمنهج إصلاح متكامل يعالج السبب الحقيقي وليس العرض الظاهري. المشكلة في جوهرها ليست شهادة SSL فقط، بل عدم تطابق بين عدة طبقات يجب أن تعمل جميعها على نفس البروتوكول بدون أي تعارض. لهذا السبب، أي حل جزئي أو متعجل غالبًا ما يخفي التحذير مؤقتًا ثم يعيده بعد تحديث قالب، أو تفريغ كاش، أو إضافة مكوّن جديد للموقع.

الإصلاح الصحيح يبدأ دائمًا من الأساس: التأكد أن شهادة SSL تعمل فعليًا على السيرفر، ثم اختيار نسخة واحدة نهائية للموقع (www أو بدون)، وبعدها ضبط عنوان الموقع داخل ووردبريس ليستخدم HTTPS بشكل صريح. بعد ذلك يتم إنشاء تحويل 301 واحد فقط واضح من HTTP إلى HTTPS على مستوى السيرفر، بدون إضافات أو قواعد متكررة. ثم تأتي خطوة حاسمة لا يمكن تجاوزها، وهي إصلاح Mixed Content بتنظيف الروابط القديمة داخل قاعدة البيانات،

لأن بقاء مورد واحد غير مشفّر كفيل بإعادة Not Secure مهما كانت باقي الإعدادات صحيحة. وفي حال استخدام Cloudflare أو Proxy، يجب ضبطه ليكون متوافقًا مع شهادة السيرفر وجعل ووردبريس يتعرف على البروتوكول الحقيقي للزائر. وأخيرًا، يتم مسح الكاش بالكامل وتنفيذ اختبار نهائي يؤكد أن الإصلاح شامل ومستقر.

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

باختصار:
إذا عالجت SSL كمنظومة متكاملة وليس كخيار منفرد، فلن تعود مشكلة Not Secure مرة أخرى، حتى مع تغيّر القالب أو الإضافات أو إعدادات الكاش.

5 أسئلة شائعة (FAQ) تقفل نية البحث نهائيًا

هل تفعيل شهادة SSL وحده يكفي لحل مشكلة Not Secure في ووردبريس؟

لا، تفعيل شهادة SSL وحده لا يكفي في أغلب الحالات. الشهادة هي خطوة البداية فقط، لكن ووردبريس يعتمد على إعدادات داخلية وتحويلات وروابط مخزّنة في قاعدة البيانات. إذا لم يتم ضبط عنوان الموقع على HTTPS، وتوحيد نسخة الدومين، وإنشاء تحويل 301 واحد صحيح، وتنظيف الروابط القديمة التي ما زالت تعمل عبر HTTP، فستستمر رسالة Not Secure في الظهور حتى لو كانت الشهادة مفعّلة وصالحة. الحل الحقيقي يكون بمعالجة المنظومة كاملة وليس جزءًا منها.

لماذا يظهر القفل مكسورًا رغم أن الموقع يعمل على HTTPS؟

ظهور القفل المكسور مع وجود HTTPS يعني غالبًا وجود Mixed Content. أي أن الصفحة نفسها تُحمّل عبر HTTPS، لكن بداخلها صور أو ملفات CSS أو JavaScript أو سكربتات يتم تحميلها عبر HTTP. المتصفح يعتبر هذا تضاربًا أمنيًا ويعرض التحذير. هذه المشكلة شائعة جدًا في المقالات أو الصفحات القديمة التي أُنشئت قبل تفعيل SSL، أو في قوالب وإضافات تحتوي روابط ثابتة. الحل يكون بتنظيف الروابط القديمة داخل قاعدة البيانات وإصلاح أي موارد ثابتة داخل القالب أو الإضافات.

لماذا يظهر خطأ ERR_TOO_MANY_REDIRECTS بعد تفعيل SSL؟

خطأ ERR_TOO_MANY_REDIRECTS يظهر عندما تتعارض التحويلات فيما بينها. يحدث ذلك غالبًا عند وجود أكثر من جهة تحاول فرض التحويل في نفس الوقت، مثل تحويل في .htaccess مع إضافة Redirect، أو إعدادات ووردبريس مع Cloudflare على وضع غير متوافق. النتيجة تكون حلقة تحويل لا نهائية بين HTTP وHTTPS أو بين www وبدونها. الحل يكون بإزالة التحويلات الزائدة، والاكتفاء بتحويل 301 واحد فقط على مستوى السيرفر، وضبط Cloudflare على Full (Strict) إذا كانت شهادة السيرفر سليمة.

هل الانتقال من HTTP إلى HTTPS يؤثر على السيو؟

عند تنفيذ الانتقال بشكل صحيح، لا يضر السيو بل يكون مفيدًا. المهم هو استخدام تحويل 301 واحد من HTTP إلى HTTPS، وتوحيد نسخة الموقع، وتحديث خرائط الموقع (Sitemap) داخل Google Search Console. عندها تفهم محركات البحث أن الانتقال دائم، وتنتقل القوة والترتيب إلى النسخة الآمنة بدون فقدان. المشاكل تظهر فقط عند تنفيذ التحويل بشكل خاطئ أو وجود نسختين نشطتين من الموقع في نفس الوقت.

كيف أتأكد أن مشكلة SSL انتهت نهائيًا ولن تعود؟

تأكد من انتهاء المشكلة فقط إذا تحققت كل النقاط التالية معًا:

  • كل الصفحات تفتح عبر HTTPS بدون تحذير

  • القفل في المتصفح يظهر طبيعيًا بدون كسر

  • لا توجد طلبات HTTP داخل أدوات المطور (Console أو Network)

  • أي رابط HTTP يتحول مرة واحدة فقط إلى HTTPS

  • لوحة التحكم /wp-admin تعمل بدون تحويلات أو تسجيل خروج مفاجئ

إذا تحققت هذه الشروط، فهذا يعني أنك أصلحت السبب الحقيقي للمشكلة، وليس مجرد إخفاء التحذير، ولن تعود Not Secure حتى بعد تحديث القالب أو الإضافات أو مسح الكاش.

author-avatar

About مصطفى ووردبريس

مصطفى مالك موقع "مصطفى ووردبريس" محترفًا ذا خبرة واسعة في نظام إدارة المحتوى ووردبريس.

Newer
بطء موقع ووردبريس: الأسباب الحقيقية وكيف تحل المشكلة خطوة بخطوة
Back to list
Older معرفة قالب ووردبريس لأي موقع بدقة 100% حتى لو كان مخفيًا