كيفية تحويل موقعك من HTTP إلى HTTPS

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

إجابة سريعة: احصل على شهادة SSL (معظم مزودي الاستضافة يصدرونها مجانًا)، ثبّتها على خادمك، غيّر عناوين موقعك من http إلى https في إعدادات منصتك، أضف إعادة توجيه 301 حتى تتبع الروابط القديمة المسار الجديد، أصلح أي عنصر ما زال يُحمَّل عبر http، ثم أضف خاصية https في Google Search Console وأعد إرسال خريطة الموقع (sitemap).

SSL (اختصار لـ Secure Sockets Layer، رغم أن جميع الشهادات الصادرة اليوم تستخدم فعليًا TLS) هو ما يجعل https ممكنًا. إذا أردت الاطلاع على الخلفية أولًا، اقرأ ما هي شهادة SSL.

كيفية التحويل من HTTP إلى HTTPS في 6 خطوات

1. احصل على شهادة SSL. مجانية من مزود الاستضافة أو من Let’s Encrypt، أو مدفوعة إذا كنت بحاجة إلى ضمان أو بيانات شركة موثّقة أو تغطية wildcard.
2. ثبّتها على خادمك. عبر لوحة الاستضافة، أو باستخدام Certbot، أو يدويًا انطلاقًا من CSR.
3. وجّه منصتك نحو روابط https الخاصة بها. كل نظام إدارة محتوى (CMS) يخزّن عنوان موقعه الخاص، ويجب تحديثه.
4. أعد توجيه http إلى https بشكل دائم باستخدام 301، على مستوى الخادم.
5. أصلح ما زال يُحمَّل عبر http: المحتوى المختلط، والروابط الداخلية المطلقة، وذاكرات التخزين المؤقت والخلاصات (feeds).
6. أبلغ محركات البحث. أضف خاصية https في Search Console، أعد إرسال خريطة الموقع، وتحقق من الروابط الأساسية (canonical).

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

قبل أن تبدأ: خذ نسخة احتياطية من موقعك وقاعدة بياناته، وإذا كانت لديك بيئة تجريبية (staging)، فجرّب التغيير هناك أولًا. اثنتان من الخطوات أدناه قد تحرمانك من الوصول إلى لوحة الإدارة الخاصة بك إذا تبيّن أن الشهادة لا تعمل، لذا فإن النسخة الاحتياطية هي الفرق بين إصلاح يستغرق خمس دقائق وبين يوم عصيب. إذا كان الموقع متجرًا إلكترونيًا، نفّذ هذا العمل خارج ساعات الذروة: كل دقيقة يتعطل فيها الدفع هي طلب مفقود.

لماذا التحويل الآن: Chrome يجعل HTTPS هو الافتراضي في أكتوبر 2026

الحجج المعتادة لصالح HTTPS ما زالت صحيحة، لكن أصبح الآن هناك موعد محدد مرتبط بها، وهذا يغيّر الحسابات بالنسبة لأي شخص لا يزال يؤجل هذا الأمر.

يعمل Chrome على تفعيل ميزة Always Use Secure Connections بشكل افتراضي، على مرحلتين. في أبريل 2026، فعّلها Chrome 147 لجميع مستخدمي وضع Enhanced Safe Browsing، وهو ما يزيد عن مليار شخص. وفي أكتوبر 2026، يمدّها Chrome 154 لتشمل جميع المستخدمين عالميًا. عند تفعيلها، يحاول Chrome استخدام https أولًا ويعرض تحذيرًا قبل تحميل موقع http عام لم يزره المستخدم من قبل.

بعبارة أخرى، إذا كان موقعك لا يزال يعمل عبر http بعد أكتوبر 2026، فإن نسبة كبيرة من زوارك ستقابلهم صفحة تحذير وسيطة قبل الوصول إليه. العناوين الخاصة، مثل أجهزة التوجيه (routers) والشبكات الداخلية (intranets)، تُعامَل بشكل مختلف ولا تُصدَر بشأنها تحذيرات افتراضيًا.

HTTPS أصبح الآن قرارًا يتعلق بالسرعة أيضًا

هذا الجانب يُغفَل في معظم أدلة الانتقال. لا يشترط HTTP/2 رسميًا التشفير، لكن لم يقم أي متصفح رئيسي بتفعيله عبر اتصالات غير مشفّرة، لذا عمليًا لا يمكنك استخدامه دون HTTPS. أما HTTP/3 فيذهب أبعد من ذلك: فهو يتطلب TLS 1.3 ولا يمتلك وضعًا غير مشفّر على الإطلاق. لذا فإن البقاء على http يحرم موقعك من كلا بروتوكولي النقل الحديثين ومن الأداء المرتبط بهما.

الأسباب المألوفة تظل قائمة أيضًا. تصنّف المتصفحات صفحات http على أنها غير آمنة (Not Secure)، وتنتقل بيانات النماذج وكلمات المرور بشكل غير مشفّر دون شهادة، وترفض بوابات الدفع العمل عبر http، وقد اعتبرت Google أن HTTPS إشارة ترتيب منذ عام 2014. هذه الإشارة الأخيرة حقيقية لكنها خفيفة الأثر، فتعامل معها كميزة إضافية لا كسبب رئيسي.

الخطوة 1: احصل على شهادة SSL

تحقق أولًا من لوحة الاستضافة الخاصة بك. تصدر معظم شركات الاستضافة الآن شهادات Let’s Encrypt مجانية عبر قسم SSL/TLS أو AutoSSL، وكثير منها قد أصدر بالفعل شهادة لا تستخدمها. الشهادة المجانية تشفّر حركة البيانات بنفس فعالية الشهادة المدفوعة؛ الفرق يكمن فيما تحقّقت منه جهة الإصدار (CA) قبل الإصدار، وما يدعمها في حال حدوث خلل.

النوع	ما تتحقق منه جهة الإصدار (CA)	مدة الإصدار	مناسب لـ
التحقق من النطاق (DV)	أنك تتحكم في النطاق	دقائق	المدونات، المواقع التعريفية، معظم المواقع الصغيرة
التحقق من المؤسسة (OV)	النطاق بالإضافة إلى المؤسسة المسجّلة	من يوم إلى 3 أيام عمل	مواقع الأعمال، مناطق الأعضاء، بوابات العملاء
التحقق الموسّع (EV)	فحص قانوني وتشغيلي كامل للشركة	من يوم إلى 3 أيام عمل	المتاجر، القطاع المالي، وأي مكان تكون فيه الهوية مهمة

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

هناك أمر يجب التخطيط له مهما كان اختيارك: شهادات Let’s Encrypt تدوم 90 يومًا ومن المفترض أن تُجدَّد تلقائيًا قبل انتهاء صلاحيتها بنحو 30 يومًا. عندما يتعطل هذا التجديد التلقائي، وهو أمر يحدث فعلًا، يظل الموقع يعمل لأسابيع ثم يصبح غير آمن دون أي تحذير. تأكد من تفعيل التجديد التلقائي، وتحقق من الشهادة مرة واحدة بعد تاريخ التجديد المتوقع الأول.

الخطوة 2: ثبّتها على خادمك

• لوحة الاستضافة. الطريقة الأسرع. في cPanel، يوجد قسم SSL/TLS ضمن Security. أصدر الشهادة للنطاق الأساسي (apex domain) وللإصدار مع www، وإلا فأي منهما تنساه سيؤدي إلى تحذير عدم تطابق الاسم.
• Certbot على خادم VPS بدون لوحة تحكم. يقوم بإصدار الشهادة، وتهيئة الخادم، وتثبيت مؤقّت التجديد التلقائي الخاص به.
• يدويًا للشهادات المدفوعة: أنشئ CSR باستخدام مولّد CSR أو أحد أكثر من 70 دليلًا لدينا حول كيفية إنشاء CSR، أكمل عملية التحقق، ثم ثبّت الشهادة والمفتاح والشهادات الوسيطة. لدينا أكثر من 80 دليل تثبيت SSL، بما في ذلك دليل cPanel.

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

الخطوة 3: وجّه منصتك نحو روابط HTTPS الخاصة بها

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

المنصة	مكان الإعداد
WordPress	Settings > General، غيّر كلًا من WordPress Address (URL) وSite Address (URL). منذ الإصدار 5.7، يقوم النواة أيضًا بإعادة كتابة الروابط غير الآمنة داخل المحتوى بمجرد أن يصبح الاثنان على https، وتوفّر أداة Site Health تحويلًا بنقرة واحدة
Joomla	System > Global Configuration > Server، اضبط Force HTTPS على Entire Site
PrestaShop	Shop Parameters > General، شغّل فحص HTTPS، اضبط Enable SSL على Yes، ثم Enable SSL on all pages، ثم احفظ. الخيار الثاني يبقى مقفلًا حتى يتم حفظ الأول
Magento 2	Stores > Configuration > General > Web، افتح Base URLs (Secure)، اضبط عنوان URL الأساسي الآمن على https، ثم اضبط Use Secure URLs on Storefront وUse Secure URLs in Admin على Yes واضغط Save Config، ثم امسح ذاكرة التخزين المؤقت. هذان الإعدادان يجعلان Magento يصدر روابط https؛ لكن إعداد المدير فقط هو من يفرض إعادة التوجيه، لذا فإن واجهة المتجر ما زالت بحاجة إلى الخطوة 4
Drupal	لا يوجد إعداد أساسي، ولا شيء في ملف .htaccess لتفعيله: القواعد المعلَّقة (commented) التي يوفّرها Drupal هناك تعيد التوجيه بين www وnon-www، وليس من http إلى https. أضف القاعدة على مستوى الخادم من الخطوة 4 إلى نفس الملف
Shopify، Wix، Squarespace	لا شيء يجب فعله. HTTPS تلقائي ولا يمكن تعطيله

يستحق صف Drupal قراءة متأنية مرتين، لأن العديد من الأدلة تخطئ في فهمه. يحتوي ملف .htaccess الخاص بـ Drupal فعلًا على قواعد إعادة توجيه معلَّقة، لذا يسهل افتراض أنها المخصّصة لـ HTTPS. لكنها ليست كذلك. هذا هو محتواها الفعلي، وهي تختار فقط بين www وnon-www:

# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

لاحظ متغير protossl في السطر الأخير: فهو يحافظ على البروتوكول الذي وصل به الطلب، لذا فإن إلغاء التعليق عن تلك القواعد يبقي الزائر عبر http على http. استخدم قاعدة Apache العادية من الخطوة 4 بدلًا من ذلك.

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

الخطوة 4: أعد توجيه HTTP إلى HTTPS بشكل دائم

صفحاتك أصبحت الآن تستجيب عبر https، لكنها ما زالت تستجيب عبر http أيضًا، وكل رابط قديم أو إشارة مرجعية أو رابط مفهرَس يشير إلى هناك. إعادة التوجيه الدائمة تصحّح هذا.

يجب أن تكون 301، وليس 302 مؤقتة. رمز 301 يخبر محركات البحث بأن الانتقال دائم. تذكر Google أن إعادة التوجيه 301 وغيرها من عمليات إعادة التوجيه الدائمة لا تسبب فقدانًا في PageRank، وهذا أمر يستحق معرفته، لأن الخوف من فقدان الترتيب هو ما يُبقي معظم المواقع على http لفترة أطول مما ينبغي.

على Apache، أضف هذا بالقرب من أعلى ملف .htaccess في جذر موقعك:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

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

على Nginx، لا يوجد ملف .htaccess. عدّل كتلة الخادم (server block):

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

اختبر باستخدام nginx -t، ثم أعد التحميل باستخدام systemctl reload nginx.

إذا واجهت رسالة ERR_TOO_MANY_REDIRECTS فور إضافة هذا، فالسبب المعتاد هو خادم وكيل (proxy) مثل Cloudflare مضبوط على وضع Flexible لتشفير SSL: فهو يتواصل مع خادمك عبر http بينما يعيد خادمك التوجيه إلى https، فيرتد الطلب بينهما ذهابًا وإيابًا. اضبط وضع التشفير على Full (strict) واحتفظ بشهادة صالحة على الخادم الأصلي.

الخطوة 5: أصلح ما زال يُحمَّل عبر HTTP

المحتوى المختلط. الصفحة المقدَّمة عبر https والتي ما زالت تجلب صورة أو نصًا برمجيًا أو ورقة أنماط (stylesheet) عبر http تُعد محتوى مختلطًا. تقوم المتصفحات بترقية بعض الموارد بهدوء، غالبًا الصور والوسائط، وترفض غيرها كليًا، وهذا ما قد يجعل الصفحة المتأثرة تظهر بلا تنسيق على الإطلاق. تظهر وحدة تحكم المتصفح (console) اسم الملف المخالف. يغطي دليلنا حول كيفية إصلاح المحتوى المختلط عملية التشخيص.

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

ذاكرة التخزين المؤقت وCDN والخلاصات. امسح ذاكرة تخزين صفحاتك المؤقتة وشبكة CDN، وإلا فإن نسخة مخزّنة مؤقتًا من صفحة http ستظل تُقدَّم بترميز قديم وتجعل الانتقال المكتمل يبدو معطلًا. ثم تحقق من الأماكن التي لا يصل إليها البحث والاستبدال في قاعدة البيانات: قوالب البريد الإلكتروني، والفواتير، وخلاصات المنتجات، وأي شيء تخزّنه خدمة طرف ثالث حول موقعك.

كيف تعرف أن الأمر نجح

أربعة فحوصات، بالترتيب.

1. اكتب عنوان http الخاص بك في متصفح وتأكد من أنه ينتهي بك إلى https بدلًا من التحميل عليه مباشرة.
2. افعل الشيء نفسه مع نسختي نطاقك، مع www ودونها، لأن الشهادة التي تغطي واحدة منهما فقط ستؤدي إلى تحذير عدم تطابق الاسم على الأخرى.
3. افتح بعض الصفحات الداخلية، لا الصفحة الرئيسية فقط، وتأكد من ظهور قفل الأمان على كل منها.
4. ثم شغّل SSL Checker مرة أخرى، فهو يكشف مشكلات السلسلة وانتهاء الصلاحية التي قد يخفيها عنك المتصفح.

الخطوة 6: أبلغ محركات البحث

• أضف خاصية https في Google Search Console. خاصية http لا تُبلغ عن روابط https. أضف الخاصية الجديدة واحتفظ بالقديمة، أو استخدم خاصية النطاق (Domain property)، التي تغطي كلا البروتوكولين معًا.
• أعد إرسال خريطة الموقع (sitemap) بروابط https. تشير Google إلى أن إرسال خريطة الموقع يسرّع عملية الاكتشاف أثناء الانتقال.
• تحقق من أن وسوم الروابط الأساسية (canonical) تشير إلى https. معظم إضافات تحسين محركات البحث (SEO) تحدّثها تلقائيًا بمجرد تغيير عنوان الموقع، لكن تأكد من ذلك في كود مصدر الصفحة.
• حدّث أدوات التحليلات ومنصات الإعلانات وأي خدمة طرف ثالث تخزّن عنوان موقعك.

لا تستخدم أداة Change of Address. هذه النقطة تُوقع حتى الأشخاص الحذرين في الخطأ، لأن تقديم طلب تغيير العنوان يبدو تمامًا كما تتوقع أن تفعله. تصنّف Google التحويل من http إلى https كانتقال موقع مع تغييرات في الروابط، لذا اتبع إرشادات Google الخاصة بانتقال المواقع. تلك الإرشادات تنص صراحةً على أنه إذا كنت تنتقل من HTTP إلى HTTPS، فلست بحاجة إلى استخدام أداة Change of Address. احتفظ بها فقط للانتقال إلى نطاق مختلف تمامًا.

ماذا تتوقع بعد ذلك

المدة التي يستغرقها العمل. على استضافة مُدارة تكون فيها الشهادة مُصدَرة بالفعل، نحو خمس عشرة دقيقة. إصدار شهادة مجانية وتهيئة المنصة، نصف ساعة. الشهادة المدفوعة تضيف فترة انتظار التحقق: دقائق للتحقق من النطاق، ومن يوم إلى ثلاثة أيام عمل للتحقق من المؤسسة أو التحقق الموسّع. إصلاح المحتوى المختلط هو الجزء المتغير ويعتمد على مقدار المحتوى الذي يحمل روابط مكتوبة بشكل ثابت (hardcoded).

المدة التي تستغرقها Google. أطول من مدة العمل نفسه. إرشادات Google بشأن انتقال المواقع تفيد بأن الموقع متوسط الحجم يحتاج إلى بضعة أسابيع لتنتقل معظم صفحاته داخل الفهرس، والمواقع الأكبر تستغرق وقتًا أطول. خلال تلك الفترة، تظهر مرات الظهور (impressions) مقسّمة بين خاصيتي http وhttps، ويتذبذب الترتيب. هذا سلوك متوقّع لانتقال الموقع، وليس علامة على وجود خلل.

بمجرد أن يستقر https لفترة، فكّر في HSTS، الذي يخبر المتصفحات برفض http العادي لنطاقك تمامًا ويسدّ الفجوة بين الطلب الأول وإعادة التوجيه. اترك توجيه preload معطلًا في البداية: فمن الصعب التراجع عنه، وسيجعل أي نطاق فرعي ما زال على http يتعذر الوصول إليه.

إذا كان هناك خلل ما زال قائمًا، فإن أدلة أخطاء SSL تتناول رموز أخطاء متصفحات محددة.

هل يمكنك العودة من HTTPS إلى HTTP؟

من الناحية التقنية، نعم، بإزالة إعادة التوجيه واستعادة روابط موقعك السابقة. لكن عمليًا، لا ينبغي لك فعل ذلك تقريبًا أبدًا. إنه انتقال موقع ثانٍ، مع جولة ثانية من اضطراب الفهرسة، وتحذيرات المتصفح تعود فورًا، وهو ما يعني بعد أكتوبر 2026 صفحة تحذير وسيطة لمعظم الزوار. وإذا كنت قد فعّلت HSTS، فإن المتصفحات سترفض http لنطاقك حتى تنتهي صلاحية السياسة، لذا فإن التراجع لن يعمل بشكل نظيف حتى.

الاستثناء الروتيني الوحيد هو التطوير المحلي، حيث تُعد شهادة موقّعة ذاتيًا أو http عادي على جهاز لا يستطيع أحد آخر الوصول إليه أمرًا طبيعيًا. إذا كان موقع مباشر (live) يعاني من سوء سلوك مع https، فإن السبب يكاد يكون دائمًا هو الشهادة أو المحتوى المختلط أو حلقة إعادة التوجيه، وإصلاح أي منها أرخص بكثير من التراجع عن عملية الانتقال بأكملها.

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

هل تدير منصة محددة؟ لدينا أدلة مفصّلة لكل من WordPress وJoomla وPrestaShop.